Christopher Baines writes: > [[PGP Signed Part:Undecided]] > > Christopher Baines writes: > >> Ludovic Courtès writes: >> >>> 2. More importantly, manually listing packages that might require >>> grafting looks like a slippery slope (“oops! we’re not getting the >>> GnuTLS graft for that CVE, too bad”). >>> >>> I designed and implemented several variants to try and delay grafting. >>> One of them consisted in carrying graft information in gexps: >>> >>> https://git.savannah.gnu.org/cgit/guix.git/log?h=wip-gexp-grafts >>> >>> It’s kinda similar to what you’re proposing in that graft information is >>> carried as far as possible. The main difference is that it’s automated. >> >> That's interesting, I think that making grafting not specific to >> packages, and something where the replacement is handled at a lower >> level (e.g. gexps) would be an alternative way to handle this. >> >> Given that this approach works though, maybe the explicit-grafting >> functionality could just sit and be used inside of (guix self). Given >> that module is very explicit about what packages are used, it should be >> possible to arrange the code so it's very hard to miss a package out, >> which should address your concern about manually listing packages (maybe >> specification->package can be tweaked so that it's possible to get all >> the packages, and that can be the list considered for grafting). >> >> I don't know of any other places where this approach would be useful, so >> while it would be nice to have a more general grafting mechanism >> eventually, I'd also like to be able to make these changes to channel >> instance grafts sooner rather than later. > > I've sent a v2 series which changes along the above lines. The explicit > grafting stuff just sits in (guix self), and (guix self) more > rigeriously uses it's own definition of specification->package, which > should provide some protection against missing packages out. Obviously > it's not quite as rigerous as moving the grafting functionality in to > gexps, but hopefully it's rigerous enough for now. This has stalled a bit, but it would be good to try and get things merged. I've gone ahead and pushed the first two patches in the series I last sent, these just make minor changes to prepare for the functional change here. I've also resent that patch as as v3.