Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On 1 April 2013 at 00:17, Ansgar Burchardt wrote:
| Dirk Eddelbuettel <edd@debian.org> writes:
| > | I assume this means that a non-working set of packages could also
| > | migrate to testing (if there was no freeze). This should probably get
| > | fixed, maybe with something similar to the perlapi-5.14.2 virtual
| > | package provided by perl(-base)?
| >
| > That is why we have a meta-variable
| >
| > ${R:Depends}
| >
| > in Depends: which gets filled by the R version that compiling the package,
| > currently 3.0.0~20130330-1. And which prevents the migration.
|
| How would it prevent a newer r-base from migrating to testing before the
| other cran-r-* packages?
Yes, that still needs a block or hold on r-base-core.
| > The same scheme worked before so I am not convinced we need something more
| > complicated or formal.
| >
| > Say six month from now we may have an R patch release 3.0.1. The packages
| > being built now (using the rc for R 3.0.0) will work.
|
| If you already have a substitution variable, doing something similar to
| the perlapi-* virtual packages would be easy. You would only have to
| rebuilt packages if the name of the virtual package changes.
I am not so sure. The change really comes from R, which is why we use the R
release number.
| Doing so would also prevent non-working package sets to be installed at
| the same time (the older cran-r-rsymphony with newer r-base case) and
| should also prevent r-base from migrating to testing on its own (which
| would make all cran-r-* packages in testing unusable).
If you truly believe that we must have that "R-API" virtual package, then
a) r-base-core (> 3.0.0-0) could provide it
b) all r-cran-* packages would depend on it.
It really does not add much as well already have a, say, Dependds:
r-base-core (>= 3.0.0~20130327) so we are really just trading one for the
other as far as I can tell.
Dirk
--
Dirk Eddelbuettel | edd@debian.org | http://dirk.eddelbuettel.com
Reply to: