Hi Ludovic, Ludovic Courtès <[email protected]> writes:
> pkill9 <[email protected]> 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. Disadvantages include potentially slower file system lookups in the replaced packages, and added complexity in Guix. I don't have an opinion on this, but I wanted to at least try to clarify the idea that pkill9 is proposing. Regards, Mark
