On Tue, May 28, 2013 at 09:16:26AM -0500, Dirk Eddelbuettel wrote:
> | Oh gosh, my bad (as I said in a follow-on email which crossed in the
> | post with yours ;-) - replace that with "R 2.14" or "R 2.10" or
> | whenever the last API change happened.
> |
> | And I'm certainly not advocating going back and modifying old packages
> | retrospectively - I'm only looking to the future.
>
> I am with you on that. Looking back, we good a one-year heads-up for R 3.0.0
> breaking. At that one point I could (and probably should) have added such a
> provides.
>
> We'll do it next time for a known "big breakage". We should however not go
> overboard and add it for R 3.1.0 just because.
I'm wondering whether we're talking at cross-purposes here? As far as
I understand it (and please do correct me if I'm wrong), there is no
intention by upstream to make R 3.1.0 binary-incompatible with R 3.0.0
modules. So r-base-core versions 3.1.0, 3.2.0 and so on should
continue to provide the r-api-3.0 virtual package (and there will be
no r-api-3.1 virtual package).
But let's say that the upstream developers in a couple of years' time
decide that R 3.5.0 will be binary incompatible with modules compiled
on earlier versions of R (as happened with R 3.0.0 and R 2.N.0 for
some values of N). At that time, from the first experimental Debian R
3.5.0 packages (say version 3.4.90-beta1 or whatever it may be
called), there will be a new Provides in the Debian package:
r-api-3.5, replacing the old r-api-3.0. Then an r-cran-foo package
built against r-base-dev 3.3.7-3, say, will have a control file line
something like:
Depends: r-base-core (>= 3.3), r-api-3.0
It will still run quite happily with r-base-core 3.4.2-6 and not need
recompiling, because that package provides r-api-3.0. But when the
binary-incompatible r-base-core 3.4.90-beta1 or 3.5.0 package is
released, it will not be able to be installed alongside the old
r-cran-foo package, because the r-api-3.0 dependency will no longer be
met. This will therefore prevent incompatible versions being
installed simultaneously, and thus protecting against broken partial
upgrades.
> | > 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.
> |
> | We do have bigger fish to fry, indeed, but if the next API change
> | happens shortly before the next Debian (stable) release, it will be a
> | real headache at that point! It seems so straightforward to pre-empt
> | that possibility with very little effort (add a "Provides: r-api-3.0"
> | to the r-base-core package and the code appearing earlier in this bug
> | report to the r-base-dev package); then an "${R:Depends}" in people's
> | source packages will make everything work perfectly in the future.
>
> Agreed in principle.
>
> Ping me off-list for help with r-cran-mgcv rebuilds. I tend to just stick
> things I need into /usr/local/lib/R/ as it is so easy and not all I need
> exists as r-cran-* ...
Thanks! Rebuilding it was easy ;-) I was just moaning at the
unnecessary step of downgrading the Build-Depends ;-)
Julian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
