Hi Mark, Mark H Weaver <m...@netris.org> skribis:
> Ludovic Courtès <l...@gnu.org> writes: > >> pkill9 <pki...@runbox.com> skribis: >> >>>> All I’m saying is that nothing can be done when the new name is longer >>>> than the old one: we just cannot graft. >>> >>> If a symlink is used though, it wouldn't matter if the new name is >>> longer, the symlink would point to the new package, and the name of the >>> symlink would match the length of the old package. >> >> But who would refer to that symlink? The thing on which the graft is >> applied can only refer to the store item that has the right length. > > If I understand correctly, pkill9's idea is that intermediate symlink(s) > (presumably one for each output of the replacement package) would have > the same length as the original store item, but could point to a > replacement store item of greater length. > > For example, whereas now we must *build* our replacement libx11 with > munged version number "1.6.A", under pkill9's approach we could instead > build it with normal version number "1.6.10", and only the intermediate > symlink(s) would have their names munged to fit within the original > length limit. The grafting process would then rewrite the original > store references to point to the symlink(s). > > An advantage to this approach is that the replacement packages would no > longer need to have their version numbers munged, which would be more > aesthetically pleasing and perhaps less confusing for users. The lack > of munging might also make the replacement package more attractive for > _direct_ usage as a package input by non-core packages that need the > newer version of the replaced package for other reasons. Oh that makes sense, thanks for explaining. It could be useful to implement this; it would make ‘--with-graft’ more generally applicable, which was pkill9’s initial goal. Package replacements often have the same length as the original, so for those we wouldn’t change anything; it would make a difference in other cases though. > Disadvantages include potentially slower file system lookups in the > replaced packages, and added complexity in Guix. Yes, though that’s probably reasonable. Thanks, Ludo’.
