[R-sig-Debian] R-3.4.0 and recommended packages
Charles Plessy
charles-r-nospam at plessy.org
Fri Apr 28 02:47:57 CEST 2017
Le Thu, Apr 27, 2017 at 01:16:11PM -0500, Dirk Eddelbuettel a écrit :
> Could you fill me in about what broke with BioC and what caused it?
As far as I understand, something changed with the c() generic, which broke
packages providing a S4 method for it. The breakage and the solution were
reported on <https://stat.ethz.ch/pipermail/bioc-devel/2017-March/010559.html>.
There was somewhere a better explanation on why it happens, but I could not
find it anymore. In brief, it has to do with the fact that upon installation,
some S4 functions capture part of their environment, and the c() declarations
in R 3.3.2 are not compatible with the c() function (or method, etc., sorry for
the imprecise vocabulary) in R 3.3.3, and therefore packages need to be
reinstalled. And since our Debian packages (and R Win/Mac pacakges) are
essentially a copy of installed packages, we need to rebuild the affected ones.
Thus, while BioC was more affected since it heavily uses S4, I would expect
that some CRAN packages were broken as well. Continuous integration of Debian's
packages did not pinpoint problems in the r-cran-* namespace, but as exemplified
by r-bioc-xvector, some regression tests have only partial coverage.
> I am not sure I understand why people would want to do partial upgrades.
> Debian stable is support. Debian testing is supported. Hybrid mixes of the
> two are risque.
I do agree and would not recommend mixes, especially since the CRAN and Debian
backports are available. But Debian officially supports partial upgrades, in
the sense that if the dependency graph allows for it, then it should work. In
that sense, preventing partial upgrades through the use of r-api-4 would be
an acceptable solution.
Have a nice day,
Charles
--
Charles Plessy
Debian Med packaging team,
http://www.debian.org/devel/debian-med
Tsurumi, Kanagawa, Japan
More information about the R-SIG-Debian
mailing list