unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Mark H Weaver <mhw@netris.org>
To: "Ludovic Courtès" <ludo@gnu.org>, pkill9 <pkill9@runbox.com>
Cc: 43984@debbugs.gnu.org
Subject: bug#43984: `--with-graft=...` doesn't work with packages of different length name/version
Date: Tue, 20 Oct 2020 18:34:00 -0400	[thread overview]
Message-ID: <87d01c8r2k.fsf@netris.org> (raw)
In-Reply-To: <87h7qobn6y.fsf@gnu.org>

Hi Ludovic,

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.

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




  reply	other threads:[~2020-10-20 22:36 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-14  0:55 bug#43984: `--with-graft=...` doesn't work with packages of different length name/version pkill9
2020-10-15  7:50 ` Ludovic Courtès
2020-10-15 18:50   ` pkill9
2020-10-16  9:31     ` Ludovic Courtès
2020-10-17  1:03       ` pkill9
2020-10-20 21:29         ` Ludovic Courtès
2020-10-20 22:34           ` Mark H Weaver [this message]
2020-10-21  8:45             ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87d01c8r2k.fsf@netris.org \
    --to=mhw@netris.org \
    --cc=43984@debbugs.gnu.org \
    --cc=ludo@gnu.org \
    --cc=pkill9@runbox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).