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.