[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: R 3.0.0 and required rebuilds of all reverse Depends: of R

On Sat, Apr 06, 2013 at 01:08:49PM +0900, Charles Plessy wrote:
> I like the idea of an api virtual package, as it requires little work from the
> parties involved and solves most of the problem.

I do not only like this but IMHO it is perfectly needed (as for any
other language system we are packaging.
>  - /usr/share/R/debian/r-cran.mk, which is used in most R packages and produces
>    the R:Depends substitution variable, would make packages depend on the r-api
>    virtual package instead of requiring a version equal or superior to the version
>    of r-base-core used at build time.

As I said previously in bug #659163 when R:Depends was introduced to regard some
R api based on the expression

    R --version | head -n1 | perl -ne 'print / +([0-9]\.[0-9]+\.[0-9])/'

which is independant from a certain package.  I do regard the currently
implemented solution as an unneeded restriction.  Compared to the
current implementation and the original suggestion in #659163 the r-api
suggestion above is certainly the cleanest and best possible solution
and I'm really in favour of this.

>  - Next time R breaks backwards compatibility, Dirk would need to modify the
>    Provides: line in debian/control and voilà, the new R core package can not
>    be installed on a system without removing or upgrading the R library packages
>    that were built with the old API.

+1 (or even +2)

> Let's discuss the details on #704805

In http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704805#10 Dirk Eddelbuettel wrote:

> I am not (yet?) sold:
>   -- there is only one "provider" or r-api-*

I can not parse whether this should be a question or a problem.
>   -- we actually do have a "greater than" relation

This is the current implementation and this is not really helpful.

>   -- the version numbers already solve this

No, they do not.  An API level is something else than a version number.

>   -- this was needed three times in ten years

There is no point in properly solving a problem only because it does not
happen very frequently.  It can perfectly happen that it occures in a
bad timing and a clean solution is always the goal we should approach
inside Debian.

> I think we are overengineering this.   

I'm in great favour of the suggestion of Charles and IMHO it is far from
overengineering - just following the usual standard procedure as it is
implemented in all comparable situations in Debian.

Kind regards



Reply to: