On 1 April 2013 at 00:17, Ansgar Burchardt wrote: | 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?
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 | e...@debian.org | http://dirk.eddelbuettel.com -- 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/20824.48507.813616.884...@max.nulle.part