On Wed, May 29, 2013 at 09:35:51AM -0500, Dirk Eddelbuettel wrote: > | That is, indeed, a problem. The other extreme, as I discovered, is > | packages that are rebuilt so frequently that they don't migrate into > | testing.... > > I agree on that. I wasn't watching for that. I tend to upgrade "my" packages > every other day or so, but then upstream generally has not more than an > upgrade per months. This ought to be the exception, not the rule. So > again, let's not overcomplicate things.
Indeed. When packages have a major upgrade which needs coordination, just as you did with the R 3.0.0 one, it usually just needs an email to the relevant maintainers saying "please don't upload a new version to unstable until the testing migration is complete". And if that doesn't work, the ftpmasters can remove the broken versions from testing to allow the transition to happen anyway. > | Mind you, coordinated upgrades should not be *that* > | difficult! > | > | Either way, having the r-api-3.0 etc. Provides/Depends system seems > | like a good thing to do for the future ;-) > > Yes, that would be a compromise as we also "inject it" automatically into > builds via the standardized debian/rules all packages have. > > It does of course neither solve nor even attempt to address the social issue > of over-eager maintainer teams adoption r-cran-* packages only to let them be > quasi-orphaned. Indeed. And in these cases, a request to ftpmaster to remove the outdated versions from testing will allow migration of the main r-base packages to testing. It doesn't solve the social issue, but it allows the development of R to continue in spite of it. Julian -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
