[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:
> Le Sun, Mar 31, 2013 at 07:02:15PM -0400, Scott Kitterman a écrit :
> > 
> > Depends: r-base-core (>= 3.0.0~20130327) , r-base-core (<< 4) 
> > 
> > or you could have an API virtual package:
> > 
> > r-base-api-3.0 
> 
> Hi Dirk and everybody,
> 
> since we already have a substitution variable in most of the R packages
> (R:Depends), I think that we can use it to address the problem.
> 
> First, let's define the problem: R broke backwards compatibility a couple of
> times since it has been packaged.  Rebuilding packages is usually done swiftly,
> but there remains the problem of transitions to Testing and updates on the
> users computers.  There is usually a gap of some years between breakages,
> so we do not want an over-engeneered solution.
> 
> I like the idea of an api virtual package, as it requires little work from the
> parties involved and solves most of the problem.  (The exception being that
> partial upgrades from Wheezy to Jessie will not be supported, but this is also
> the case in the current situation).

In short: That is not an exception but THE intention. It's the whole
point of having an api virtual package.

In long: The R package breaks compatibility in such a way that a
partial upgrade simply won't be functional. You either update them all
or none. Till now installing any package compiles against a newer R
API would pull in the newer r-base-core package to fullfill its
version requirement but would not force old R packages already
installed to also be updated. This leads to procken packages on
partial update. Introducing the api virtual package will enforce that
all R packages will be compiled against the same R API, against a
compatible r-base-core. Installing one package compiled against the
new R will force apt/aptitude to also update all the already installed
R packages, which is what is required.

>  - /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.

It might be enough to only depend on the api or you might need both,
the api virtual package and a versioned depends for a minimum version.
But that depends on the circumstances. Design it so that it is easy to
have both and so that you don't miss updating the minimum version when
required.
 
>  - 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.

It might make sense to have a single file "r-api-virtual-version" (or
so) in the source and generate the Provides: field and
/usr/share/R/debian/r-cran.mk from that single source.
 
> Let's discuss the details on #704805
> 
> Have a nice week-end,

MfG
	Goswin


Reply to: