On 5 April 2014 at 02:48, Vincent Danjean wrote: | On 04/04/2014 16:27, Dirk Eddelbuettel wrote: | > | It would also mean that the critical r-base transition to testing can | > | only happen when all of the depending add-on packages have been | > | upgraded or removed from testing, making the transition far, far | > | smoother. Yes, it may only happen once every five years, but the pain | > | was significant last time, and this is a very simple way to avoid that | > | next time round. | > | > This is where we differ. I did not see the last (or previous) transition as | > painful. At all. [1] | | It has been for me. Me and some colleagues did partial upgrades of R as | we need a r-package that need a newer r-core. And, suddenly, lots of other | r packages stopped working. | The workaround have been to force the upgrade of all r-* installed | packages. But it means that all theses packages are now marked as | manually installed (whereas most of them was dependencies).
Well I personally upgraded my large set of r-cran-* packages within days. I pestered other maintainers to do it for theirs. This report, months after the fact, does not help all that much as it lacks information about _which_ packages failed and _how_. | Currently, R is unusable with partial upgrade between stable and | testing. However, this is something that we must support (and that have | a severity above normal) Not ideal but I don't think that partially upgrades between stable and testing are a goal of the project or distribution. The goal is to get testing where we can cut a new stable. If current testing works... | > [1] I have one persistent pain point, but that is unrelated to the transition | > and your proposal. Well maybe it is related: there are group-maintained | > r-cran-* packages that are simply poorly maintained. Look at the Debian QA | > pages, some slip behind a few upstream releases. In that context I do not | > want a poorly maintained package to block the transitiont of R itself. | | When this happens on other cited examples, the maintainer request the | removal from testing of the offending (not updated) packages. In any case, | they do not work with the new R. Better remove them (from testing) quickly | instead of having to detect them manually latter and mark them as RC. We can do that now too. A new tag 'r-api-version' of whatever is not needed for removals. I still feel that the suggested approach may be too heavy-handed. Dirk | Regards, | Vincent | -- | Vincent Danjean GPG key ID 0xD17897FA vdanj...@debian.org | GPG key fingerprint: 621E 3509 654D D77C 43F5 CA4A F6AE F2AF D178 97FA | Unofficial pkgs: http://moais.imag.fr/membres/vincent.danjean/deb.html | APT repo: deb http://people.debian.org/~vdanjean/debian unstable main -- Dirk Eddelbuettel | e...@debian.org | http://dirk.eddelbuettel.com -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
