`--with-graft=...` doesn't work with packages of different length name/version

  • Open
  • quality assurance status badge
Details
3 participants
  • Ludovic Courtès
  • Mark H Weaver
  • pkill9
Owner
unassigned
Submitted by
pkill9
Severity
normal
P
P
pkill9 wrote on 14 Oct 2020 02:55
(address . bug-guix@gnu.org)
20201014015558.09d6702a@runbox.com
As expected, if you attempt to graft a package's dependency, and it's
name + version is different length to the original dependency, then it
will fail to graft.

Maybe if the length/version is different, then a symlink could be
created in the store pointing to the new dependency, with a
name/version that matches the length of the original dependency's store
name? Perhaps this new name/version could be something like
/gnu/store/...-original-dependency-name-gggggg, where 'g..' matches the
length of the version of the original dependency. The many 'g's would
make it clear that it is a graft. Then if someone looks in the store,
they would see it's a symlink too.
L
L
Ludovic Courtès wrote on 15 Oct 2020 09:50
(name . pkill9)(address . pkill9@runbox.com)(address . 43984@debbugs.gnu.org)
87wnzsapwh.fsf@gnu.org
Hi,

pkill9 <pkill9@runbox.com> skribis:

Toggle quote (4 lines)
> As expected, if you attempt to graft a package's dependency, and it's
> name + version is different length to the original dependency, then it
> will fail to graft.

Yes, that’s expected, but perhaps the manual could state it more
prominently?

Toggle quote (9 lines)
> Maybe if the length/version is different, then a symlink could be
> created in the store pointing to the new dependency, with a
> name/version that matches the length of the original dependency's store
> name? Perhaps this new name/version could be something like
> /gnu/store/...-original-dependency-name-gggggg, where 'g..' matches the
> length of the version of the original dependency. The many 'g's would
> make it clear that it is a graft. Then if someone looks in the store,
> they would see it's a symlink too.

That only works if the new name is shorter than the old name though.
When the new name is longer (which is a more common case in our
experience when introducing package replacements, typically because the
new version string is longer), nothing can be done.

I’m tempting to keep things as is.

Thoughts?

Ludo’.
P
P
pkill9 wrote on 15 Oct 2020 20:50
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43984@debbugs.gnu.org)
20201015195013.335eaefd@runbox.com
Toggle quote (14 lines)
> > Maybe if the length/version is different, then a symlink could be
> > created in the store pointing to the new dependency, with a
> > name/version that matches the length of the original dependency's
> > store name? Perhaps this new name/version could be something like
> > /gnu/store/...-original-dependency-name-gggggg, where 'g..' matches
> > the length of the version of the original dependency. The many 'g's
> > would make it clear that it is a graft. Then if someone looks in
> > the store, they would see it's a symlink too.
>
> That only works if the new name is shorter than the old name though.
> When the new name is longer (which is a more common case in our
> experience when introducing package replacements, typically because
> the new version string is longer), nothing can be done.

I'm confused about what you mean. Why would it matter if the new
name is longer than the old name?
L
L
Ludovic Courtès wrote on 16 Oct 2020 11:31
(name . pkill9)(address . pkill9@runbox.com)(address . 43984@debbugs.gnu.org)
87sgae8qlh.fsf@gnu.org
pkill9 <pkill9@runbox.com> skribis:

Toggle quote (17 lines)
>> > Maybe if the length/version is different, then a symlink could be
>> > created in the store pointing to the new dependency, with a
>> > name/version that matches the length of the original dependency's
>> > store name? Perhaps this new name/version could be something like
>> > /gnu/store/...-original-dependency-name-gggggg, where 'g..' matches
>> > the length of the version of the original dependency. The many 'g's
>> > would make it clear that it is a graft. Then if someone looks in
>> > the store, they would see it's a symlink too.
>>
>> That only works if the new name is shorter than the old name though.
>> When the new name is longer (which is a more common case in our
>> experience when introducing package replacements, typically because
>> the new version string is longer), nothing can be done.
>
> I'm confused about what you mean. Why would it matter if the new
> name is longer than the old name?

All I’m saying is that nothing can be done when the new name is longer
than the old one: we just cannot graft.

Ludo’.
P
P
pkill9 wrote on 17 Oct 2020 03:03
(name . Ludovic Courtès)(address . ludo@gnu.org)(address . 43984@debbugs.gnu.org)
20201017020311.0c68f3d5@runbox.com
Toggle quote (3 lines)
> 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.
L
L
Ludovic Courtès wrote on 20 Oct 2020 23:29
(name . pkill9)(address . pkill9@runbox.com)(address . 43984@debbugs.gnu.org)
87h7qobn6y.fsf@gnu.org
Hi,

pkill9 <pkill9@runbox.com> skribis:

Toggle quote (7 lines)
>> 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.

Ludo’.
M
M
Mark H Weaver wrote on 21 Oct 2020 00:34
(address . 43984@debbugs.gnu.org)
87d01c8r2k.fsf@netris.org
Hi Ludovic,

Ludovic Courtès <ludo@gnu.org> writes:

Toggle quote (12 lines)
> pkill9 <pkill9@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.

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
L
L
Ludovic Courtès wrote on 21 Oct 2020 10:45
(name . Mark H Weaver)(address . mhw@netris.org)
87sga89dcw.fsf@gnu.org
Hi Mark,

Mark H Weaver <mhw@netris.org> skribis:

Toggle quote (33 lines)
> Ludovic Courtès <ludo@gnu.org> writes:
>
>> pkill9 <pkill9@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.

Toggle quote (3 lines)
> Disadvantages include potentially slower file system lookups in the
> replaced packages, and added complexity in Guix.

Yes, though that’s probably reasonable.

Thanks,
Ludo’.
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 43984@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 43984
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch