On Sat, Apr 05, 2014 at 09:21:33PM +0200, Vincent Danjean wrote: > The disagreement comes from the fact that the maintainer does not > think that he must declare this incompatibility. > For now, if you install a r package from testing, it will pull > the r-base-core from testing (due to dependency such as > "Depends: r-base-core (>= 3.0.2-1)") > But, when r-base-core from testing is installed, the system keeps > other r related packages from stable (no conflict, break, ...) > and these packages won't work anymore.
> The maintainer think that he does not need to do anything about > that. People should just upgrade all their packages from stable to > testing when r-base-core is upgraded. > Other people (and me) disagree and think that other broken r-related > packages must be either removed or upgraded automatically by apt > when r-base-core is upgraded (due to additional conflicts/breaks/... > declarations) Packages that are incompatible between stable and testing are expected to declare these incompatibilities - not least of all because the declarations used to ensure that partial upgrades work are identical to the declarations needed for apt to compute a proper dist-upgrade. Sometimes, a dist-upgrade between releases *doesn't work*; and when this happens, our users rely on the dpkg status database correctly describing the current state of the packages' usability, so that they can work out what to do to recover from a failed dist-upgrade. If Breaks/Depends information between packages is missing or inaccurate, the package manager doesn't have the information needed to keep the system in a coherent state (and neither does the admin driving it). There are also plenty of cases for which you'll get wrong results even in a *successful* dist-upgrade, without properly-declared depends/breaks. Consider the hypothetical package r-cran-apple that has a version in wheezy that Depends: r-base-core (>= 2.14.1). Now, upstream goes away and the package is removed from the archive; or the package is RC-buggy and fails to be included in the jessie release. What happens on dist-upgrade? apt happily upgrades to an incompatible r-base-core; but leaves r-cran-apple installed at the wheezy version because no newer version is available. Similarly, suppose you have a package r-cran-krb5 which provides bindings to the MIT Kerberos libraries (don't ask me why); and you have those libraries pinned at the wheezy versions, or marked in dpkg as 'held', because your site's installation requires some particular patches not available upstream and they have not yet been ported to the testing version of the package.[1] In this case, apt will calculate a dist-upgrade that includes r-base-core, but will hold back both libkrb5-3 and all packages depending on it (since the newer versions have a versioned dependency on a newer libkrb5-3), including r-cran-krb5. This dist-upgrade solution is perfectly allowed, because the Breaks information is missing that would tell apt not to upgrade r-base-core without also upgrading r-cran-krb5! These issues are much more severe with packages in the base system than they would be with a self-contained "leaf" of packages like R, but there is no reason that R packages should be exempted from these basic principles of how Debian packaging works. Obviously, with so many reverse-dependencies of r-base-core in the archive, and possibly more outside the archive, it's quite cumbersome to maintain a Breaks: list of all of them. For this reason, in the long term it's better to emulate the shlibs system used by C shared libraries in Debian: auto-generated dependencies that reference a particular ABI version, ensuring that when the ABI of the depended-on package changes the dependency is no longer satisfied. E.g.: - immediately rename r-base-core to r-base-core-3, with versioned Breaks/Replaces against r-base-core - make r-base-core a temporary transitional package which Depends: r-base-core-3, to keep the system installable in the near term - possibly add a Provides: r-base-core-3.0 (to allow changing the ABI declaration in the future without having to change the package name; if you will never be able to install more than one major version of r-base-core on the system at a time due to file conflicts, then you don't want to rename the package for each ABI change) - adjust /usr/share/R/debian/r-cran.mk to generate dependencies against r-base-core-3 (or r-base-core-3.0, if you go that route) - rebuild all reverse-dependencies of r-base-core in unstable - drop the r-base-core transitional package. Hope that helps, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org [1] But of course your site admin is responsible, and forward-ports the patches each time there's a security update of krb5 in wheezy!
signature.asc
Description: Digital signature
