GNU bug report logs - #43984
`--with-graft=...` doesn't work with packages of different length name/version

Previous Next

To reply to this bug, email your comments to 43984 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: pkill9 <pkill9 <at> runbox.com>
To: bug-guix <at> gnu.org
Subject: `--with-graft=...` doesn't work with packages of different length
 name/version
Date: Wed, 14 Oct 2020 01:55:58 +0100

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.

Message #8 received at 43984 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: pkill9 <pkill9 <at> runbox.com>
Cc: 43984 <at> debbugs.gnu.org
Subject: Re: bug#43984: `--with-graft=...` doesn't work with packages of
 different length name/version
Date: Thu, 15 Oct 2020 09:50:54 +0200

Hi,

pkill9 <pkill9 <at> runbox.com> skribis:

> 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?

> 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’.

Message #11 received at 43984 <at> debbugs.gnu.org (full text, mbox):

From: pkill9 <pkill9 <at> runbox.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43984 <at> debbugs.gnu.org
Subject: Re: bug#43984: `--with-graft=...` doesn't work with packages of
 different length name/version
Date: Thu, 15 Oct 2020 19:50:13 +0100

> > 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?

Message #14 received at 43984 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: pkill9 <pkill9 <at> runbox.com>
Cc: 43984 <at> debbugs.gnu.org
Subject: Re: bug#43984: `--with-graft=...` doesn't work with packages of
 different length name/version
Date: Fri, 16 Oct 2020 11:31:06 +0200

pkill9 <pkill9 <at> runbox.com> skribis:

>> > 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’.

Message #17 received at 43984 <at> debbugs.gnu.org (full text, mbox):

From: pkill9 <pkill9 <at> runbox.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 43984 <at> debbugs.gnu.org
Subject: Re: bug#43984: `--with-graft=...` doesn't work with packages of
 different length name/version
Date: Sat, 17 Oct 2020 02:03:11 +0100

> 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.

Message #20 received at 43984 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: pkill9 <pkill9 <at> runbox.com>
Cc: 43984 <at> debbugs.gnu.org
Subject: Re: bug#43984: `--with-graft=...` doesn't work with packages of
 different length name/version
Date: Tue, 20 Oct 2020 23:29:57 +0200

Hi,

pkill9 <pkill9 <at> 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.

Ludo’.

Message #23 received at 43984 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Ludovic Courtès <ludo <at> gnu.org>, pkill9 <pkill9 <at> runbox.com>
Cc: 43984 <at> debbugs.gnu.org
Subject: Re: bug#43984: `--with-graft=...` doesn't work with packages of
 different length name/version
Date: Tue, 20 Oct 2020 18:34:00 -0400

Hi Ludovic,

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

> pkill9 <pkill9 <at> 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

Message #26 received at 43984 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: Mark H Weaver <mhw <at> netris.org>
Cc: pkill9 <pkill9 <at> runbox.com>, 43984 <at> debbugs.gnu.org
Subject: Re: bug#43984: `--with-graft=...` doesn't work with packages of
 different length name/version
Date: Wed, 21 Oct 2020 10:45:19 +0200

Hi Mark,

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

> Ludovic Courtès <ludo <at> gnu.org> writes:
>
>> pkill9 <pkill9 <at> 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’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.