Dirk Eddelbuettel <e...@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?
> 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.
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).
Ansgar
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/877gknrz7w....@deep-thought.43-1.org
