On Sun, 31 Mar 2013 17:45:15 -0500 Dirk Eddelbuettel <edd@debian.org> wrote: > On 1 April 2013 at 00:16, Josselin Mouette wrote: > | I don’t understand how you can say it “worked before”. > | Let’s say you backport a R package from wheezy to squeeze (something we > | tried recently at work). The new R will install without a dependency > | problem, and… all modules will stop working. > | > | > Testing is fine, but within unstable the transition has to be done. > | > | Testing is not fine. The new R version could migrate to testing without > > Not if we blocked it. That's what I was trying to suggest. So you are relying on the release process to provide the block? Having the new version in unstable is much more likely to cause problems with backports as other packages will change to match the new API and then need those changes undone to be backportable. > r-base_3.0.0~20130330 is one day old, there should be a new r-base_3.0.0-1 come > April 3. ... or an epoch could be used to put unstable back to what is in testing and 3.0.0 could go into experimental, introducing the maximum version limitation and API versioning at the same time. > | There are reasons why other interpreters have complex dependency > | schemes: previously to avoid that. Not only your reverse dependencies > | should only depend on the *sufficient* version of R (in this case, > | certainly not the R version used to compile the package, which will lead > | to transition blockades to testing), but they should stop installing > | when the version of R becomes incompatible, and so far nothing > | guarantees that. > | > | Perl has a perlapi-X.Y virtual package to avoid that. > | Python generates python (<< X.Y) dependencies to avoid that. > | There are tons of similar schemes used across the Debian archive to > | avoid such problems, from virtual packages, through autogenerated > | dependencies, to package renames. > | > | It’s OK if you don’t know the best way to do that for your package. This > > We did not need for the previous 15 years that R has been part of Debian. How many R transitions have been done during a release freeze? How many at this perilously late stage of a release freeze? A lot of things can be done early in a release freeze and only cause a slight delay, if any. It is simply not possible to handle API changes in unstable at this stage of a release without *directly* delaying that release. The discussion of the rebuild request alone has required the attention of people from the FTP team, wanna-build team, release team and other DD's actively working on the release. Just because it hasn't caused a big discussion before doesn't mean that it wasn't a problem, just that it wasn't a big enough problem for lots of people to get involved. > If > the release team strongly insists that I ought to add this, I can. It has > not been needed before. > > And Perl is an odd example as there are multiple APIs / versions used in > parallel. We don't usually do that with R. Unstable now has a different API and version to testing, yes? Testing has a different API to stable (squeeze)? (I'm not sure) Wheezy will definitely have a different API to Jessie, so backporters will clearly need this kind of API version support. Looks like multiple APIs / versions are inevitable, block or no block. If multiple APIs / versions are never going to happen, then the API version support can be avoided. If there is any situation (i.e. as now) where multiple versions are desirable from your perspective (clearly not desirable from the release perspective, right now) then your own requirements mandate a change. Personally, I agree with Josselin - R looks like it needs precisely the same kind of API version limits as python or perl. Packages built for the old API must not allow installation of a version of the interpreter which breaks the API required by those packages until those packages have been rebuilt and have a dependency suitable for the new API. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpOelCMtuwlH.pgp
Description: PGP signature