On Wed, Mar 21, 2018 at 02:38:30PM -0400, Chris Lawrence wrote: > On Mar 21, Sébastien Villemot wrote: > > This proposed scheme does not help for the case where we have to rebuild both > > arch:any and arch:all. But it helps when only arch:any need rebuilds (as for > > the R 3.4 transition). > > Query - is it strictly necessary for us to have a hard dependency on > the r-api-x.y version in the arch:all packages? My understanding is > these should only have R/S code in them, and the R language is pretty > stable, so unless there's a backward-incompatible change in the core > language (like fundamental changes in syntax, like getting rid of the > legacy "_"-as-assignment was) can't we just rely on a standard minimum > dependency on R (>= 3.4.0-1)? Even though arch:all packages ship only R code, they still get bytecompiled (into .rds file), so there is a potentially an ABI-compatibility issue if that format changes. Still, the ABI tracking for arch:all is very different from that for arch:any, so this could justify using two different ABI-like pseudo-packages, as I advocated earlier in this thread. > Obviously this wouldn't help with the 3.5 transition but it would > dramatically simplify things for future ones if we could go ahead and > remove the r-api-x.y dependencies in arch:all packages while doing > the 3.5 transition, assuming there's not something I'm missing > here. All we'd need to do is adjust the arch:all packages to use a > different substvar omitting r-api-x.y, which is a little more work > than a manual rebuild but probably could be automated to some extent. I agree that *right now* is the ideal timing to implement a change in the ABI tracking machinery, since we are going to update all packages if a few weeks. -- ⢀⣴⠾⠻⢶⣦⠀ Sébastien Villemot ⣾⠁⢠⠒⠀⣿⡁ Debian Developer ⢿⡄⠘⠷⠚⠋⠀ http://sebastien.villemot.name ⠈⠳⣄⠀⠀⠀⠀ http://www.debian.org
Attachment:
signature.asc
Description: PGP signature