On 8 September 2017 at 20:01, Sébastien Villemot wrote: | Hi Dirk and others, | | On Fri, Sep 08, 2017 at 12:29:25PM -0500, Dirk Eddelbuettel wrote: | | > | The problem is that you can end up with r-bioc-makecdfenv_1.50.0-1 (i.e. before | > | the rebuild) and r-base_3.4.1-2, because nothing prevents that combination. | > | > You may misunderstand. Only packages that | > | > - have compiled code (ie arch: any, and a src/ directory) | > - use .C() and .Fortran() | > - actually use the up until recently optional registration | > - have been built with R (<< 3.4.0) | | The point made by the Release Team is that packages that fulfill these 4 | criterias may still be installed on system where R has been upgraded to 3.4.
Which is why we want to update all such packages, hence my 'please NMU' request to the release team. | Such a bad combination can happen if a user does a partial upgrade from stretch | to (upcoming) buster, by upgrading R core but not the CRAN packages fulfilling | the 4 criterias. In that case the user ends up with a broken system (in the | sense that those non-upgraded CRAN packages are not functional). | | I understand that this situation is not going to happen very often, but it may | happen, and the Release Team wants to prevent this by introducing a Breaks | relationship. | | Of course, please correct me if I am wrong. I still maintain that this is a useless "academic" consideration. If users want to corrupt their systems by only upgrading one package I will not stop them. They can simply fix them by also upgrading the package left behind. I aim for 'apt-get dist-upgrade' doing the right thing for them. It will automate this. Dirk | | Cheers, | | -- | ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot | ⣾⠁⢠⠒⠀⣿⡁ Debian Developer | ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name | ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org | [DELETED ATTACHMENT signature.asc, application/pgp-signature] -- http://dirk.eddelbuettel.com | @eddelbuettel | [email protected]
