Blacklisting packages that expect to be able to write to their system directory
Closed this issue · 7 comments
I'm using bspm and the ubuntu binaries packaged by https://github.com/eddelbuettel/r2u, on Ubuntu 22.04
A particular example here is showtextdb which installs fine via bspm / r2u and works as expected except the showtextdb::google_fonts("Roboto") function does not work, as it cannot write to system.file("fonts", package = "showtextdb") which it expects to be installed as a user library.
I would have thought this behaviour in showtextdb is not unique. I suspect it it not fully in line with CRAN package policy either.
It would be useful to be able to blacklist package installation by bspm for things such as showtextdb, and fall back to normal system installation, unless maybe there is a better way of doing this?
Many thanks!
Yes, Maybe there is an apt or dpkg way to do this? I sort-of remember that (some of is at different times) have done shadow or virtual packages. For example in Debian proper the current r-cran-bh is not a full copy of my large (100+ mb) BH package but just a shallow package with a dependency on the (system) libboost-all-dev (or maybe a boost subset).
Similarly, I think I stopped littler from building under r2u (or maybe I enforced a rebuild) as the binary it gets from RSPM is unuseable as a wrong path gets encoded.
So along those lines I would encourage you to think about way to keep R happy (by having a showtextdb package) without making too much work for the system. But maybe a patch to bspm to respect a 'do not touch packages from this list' may have merit. Do you want to try an initial PR?
A simple hack may be to fork the upstream package, add a minimal delta to the version number and install that locally. You would have to do that each time upstream changes. Or you could avoid that via a Yuge value for the delta.
No package is expected to write to its installation directory. This is a violation of CRAN policies, and should be reported upstream (and to CRAN). I'm sorry to be blunt, but we cannot keep mending someone else's issues. This package should use tools::R_user_dir to find a proper path to store user data, and stop modifying its own installation directory.
I would be willing to implement some kind of dynamic blacklisting mechanism if we find some proper use case, but not for this, I'm sorry. Meanwhile, as a workaround, you could disable bspm, install the problematic package and reenable bspm. If there's an apt hack, that would do too.
But above all, I encourage you again to bring this upstream. Thanks for the report.
You are of course correct in the narrow sense. In the wider sense we may well have packages that, say, do things at startup that are not CRAN compatible and need a flag.
I was thinking that this would be pretty hard to implement anyway as you would need to blacklist apt's transitive dependencies as well to prevent it from installing the problematic package as a dependency of something else. You couldn't just do it in R.
You couldn't just do it in R.
Have you see my RcppAPT package? 😀
You are of course correct in the narrow sense. In the wider sense we may well have packages that, say, do things at startup that are not CRAN compatible and need a flag.
As I said, if we find some reasonable (and reasonably common) use case, I'm not against the idea, and we could discuss that in a separate issue---in fact, note that, as documented in the README, blacklisting is already possible at (bspm) installation time via PKG_EXCL (only that PKG_PREF must be specified manually too)---. But not for this, I don't think that any package should modify its own (or other) installation directory, CRAN or not.
I was thinking that this would be pretty hard to implement anyway as you would need to blacklist apt's transitive dependencies as well to prevent it from installing the problematic package as a dependency of something else. You couldn't just do it in R.
Yeap, that is a problem. This would be like basically dropping this package from r2u along with all the dependent ones. Technically possible but potentially pretty disruptive. So again disabling bspm just to install this package is easier for everyone.
Thanks again, closing here.