Le 28/05/2013 15:33, Dirk Eddelbuettel a écrit :
> There is no such thing as an "R 2.7" API, and as long as upstream does not
> define one I do not plan to jump into the frey and meddle with it.
>
> The status quo works well enough, but I will acknowledge the breakage you got
> with that r-cran-mgcv package. But I think we have bigger fish to fry.
I really disagree here.
Upstream is perhaps not interested into defining a proper ABI.
But the fact is that sometimes the R ABI is broken by upstream
and, at this point, all Debian packaging mess up as soon as
either the user do not wait enough for all package to be rebuilt
*or* the user do a partial upgrade from the previous release
(ie mixing old and new r-package on its installation). The
second point (partial upgrade) is something that is supported
by Debian.
R is not the only one software in this case. The most used that
come into my mind is the Linux kernel itself.
Linux kernel maintainers do a great job to ensure, when upgrading
minor version, that modules are still compatible or not.
Maintainers decide on case-by-case bases to bump or not
the *debian-specific* ABI version (they have tools to help them).
The 'current' ABI for 3.8 kernel is the second from the first
packaging of 3.8.x:
linux-image-3.8-2-amd64
^
Moreover, you have all required tools in Debian to do better
dependencies. It has already been discussed in this bug report.
For future breakage, if you want to support only one R version
(as currently), introducing a [debian-]ABI version as a
virtual package would avoid you the need to change the name of
the core R package.
For the current 'transition', as old Debian R-packages only have
a relation of the type "r-base-core (>= X)", the only good solution
I see is:
- rename the r-base-core into another name (r-base-core3 for example)
- r-base-core3 must replace *and* conflict with r-base-core
- all rebuilt Debian R-packages must now depends on r-base-core3
(or better, on r-base-core-debianabi-X that would be a virtual
package provided by the current r-base-core3)
By doing this, you would ensure that partial upgrade between
wheezy and testing will never break user software (either the
upgrade will be refused by apt or all installed r-packages will
be also updated to a compatible version)
Of course, all of this will really works once all packages
in testing/unstable depending on "r-base-core (>=3.xxx)" will
have disappear (ie once all of them will have been rebuilt
with the new dependency).
At this time, partial upgrades between wheezy and testing
will work correctly.
Regards,
Vincent
Note: is you really do not want to rename you r-base-core package,
you can keep it but you then will need to add a versionned Breaks:
dependency for all previous (before R 3.x) Debian R-packages.
As I know that there exists lots of Debian R packages outside
of the main archive, it seems to me that this is a worst solution
as a rename of r-base-core.
> Dirk
>
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
