On Tue, May 28, 2013 at 08:33:14AM -0500, Dirk Eddelbuettel wrote:
> | So because of the new version in sid, which didn't wait for the R
> | 3.0.0 migration to testing, the jessie version is still an R 2.7
> | version :-( Had there been a "Provides: r-api-3.0" in r-base-core and
> | "Depends: r-api-2.7" in r-cran-mgcv, the transition would either have
> | been delayed or knowingly pushed though in spite of this, but the
> | breakage would have been caught at the time. (Then again, this might
> | have been the case anyway.)
>
> 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.
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.
> 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.
Julian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
