Re: R 3.0.0 and required rebuilds of all reverse Depends: of R
On Sunday, March 31, 2013 05:49:31 PM Dirk Eddelbuettel wrote:
> 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.
If that's as far as you take it, you are correct. That doesn't change
anything. To solve this problem you need both a minimum and a maximum
version. Assuming the API goes change between major versions, the relevant
packages could then depend on (if you just generate a dependency):
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
All packages could depend on that. When you move to R 4.0 you'd generate a r-
base-api-4.0 virtual package that the rebuilt packages would depend on.
Either approach can give you an effective minimum and maximum version that the
package will work with, which is what you need.
Scott K
Reply to: