On Wed, Mar 21, 2018 at 08:19:12AM -0500, Dirk Eddelbuettel wrote: > > On 21 March 2018 at 10:38, Sébastien Villemot wrote: > | On Tue, Mar 20, 2018 at 05:14:04PM -0500, Dirk Eddelbuettel wrote: > | > | > I don't recall what we did with 5. and arch:all. If it really is a manual > | > step, that would suck. (But then recall my email; at least we get the > | > bytecode compiler benefit out of it.) > | > | For the R 3.4 transition, this work was done by Andreas Tille, Graham Inggs and > | myself IIRC; we collectively did several dozens of uploads of arch:all > | CRAN/BioC packages. > > Sure, and so did I with my few dozen r-cran-* package with arch:all. Actually, no, I NMU'ed them all. > If at some point you can think of a more manageable and automated way that > passes muster with the release team let me know. ;-) > > The r-api-x.y tag was supposed to take care of this, and only does it > partially. Better than nothing, yet still not as good as we need it to be. If arch:all packages have to be rebuilt, there's nothing that we can do to improve the process, since this has to be solved at the level of Debian infrastructure (but I think people are working on it, so one day it may be possible to rebuild them). What we could however do at our level is to have two virtual packages instead of one (r-api-x.y). One of the virtual package would be for arch:any, the other one for arch:all, so that we could increment one and not the other if only arch:any have to be rebuilt. But in any case, it is too late for this specific transition. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: PGP signature