From: zimoun <zimon.toutoune@gmail.com>
To: Mark H Weaver <mhw@netris.org>, Andreas Enge <andreas@enge.fr>
Cc: guix-devel@gnu.org
Subject: Re: imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2
Date: Wed, 24 Mar 2021 11:15:05 +0100 [thread overview]
Message-ID: <86czvohn86.fsf@gmail.com> (raw)
In-Reply-To: <871rc5jv1o.fsf@netris.org>
Hi Mark,
On Tue, 23 Mar 2021 at 19:42, Mark H Weaver <mhw@netris.org> wrote:
> Andreas Enge <andreas@enge.fr> writes:
>> $ guix package -A imagemagick
>> imagemagick 6.9.12-2g out,doc gnu/packages/imagemagick.scm:132:2
>> imagemagick 6.9.11-48 out,doc gnu/packages/imagemagick.scm:48:2
>>
>> $ guix build imagemagick@6.9.11
>> guix build: error: imagemagick: package not found for version 6.9.11
>>
>> $ guix build imagemagick@6.9.11-48
>> /gnu/store/c30y49vg735g6b4hh590zrc9fmvcsy0w-imagemagick-6.9.12-2g-doc
>> /gnu/store/l3hr0fimip6v7vmkgxbqygsglxaxasy0-imagemagick-6.9.12-2g
Here, there are several points.
--8<---------------cut here---------------start------------->8---
$ guix search imagemagick | recsel -p name,version | head -5
name: imagemagick
version: 6.9.12-2g
name: imagemagick
version: 6.9.11-48
$ guix build imagemagick
/gnu/store/b91y6ji9ypx8abk00jd33jglxbnjq4dy-imagemagick-6.9.12-2g-doc
/gnu/store/l0asah1mggmgli85sp673bnp2yc71g0j-imagemagick-6.9.12-2g
--8<---------------cut here---------------end--------------->8---
All is fine, security speaking.
Then, there is a bug on how Guix handles the version. Well, 6.9.11
should be understood as 6.9.11-48 and it seems not:
--8<---------------cut here---------------start------------->8---
$ guix build imagemagick@6.9.11
guix build: error: imagemagick: package not found for version 6.9.11
$ guix build imagemagick@6.9.11-48
/gnu/store/b91y6ji9ypx8abk00jd33jglxbnjq4dy-imagemagick-6.9.12-2g-doc
/gnu/store/l0asah1mggmgli85sp673bnp2yc71g0j-imagemagick-6.9.12-2g
--8<---------------cut here---------------end--------------->8---
…but all is fine security speaking. And the --no-grafts allows to get
the so-well named option. :-)
--8<---------------cut here---------------start------------->8---
$ guix build imagemagick@6.9.11-48 --no-grafts
/gnu/store/wlnciwhn6llwqwywf4hq739v5bbcrq3h-imagemagick-6.9.11-48-doc
/gnu/store/vlix7fclb7ifjgmxgpwr1pvraff89w7b-imagemagick-6.9.11-48
--8<---------------cut here---------------end--------------->8---
However, I am confused by,
--8<---------------cut here---------------start------------->8---
$ guix build imagemagick --no-grafts
/gnu/store/aby97j4d27zm6ilpcqrdm1lcw34xhcpj-imagemagick-6.9.12-2g-doc
/gnu/store/mzlng0n9s811abilzffa3v6pslv184yj-imagemagick-6.9.12-2g
--8<---------------cut here---------------end--------------->8---
> To my mind this suggests a bug, or at least suboptimal behavior, in
> "guix package". I don't think it's appropriate to set grafting policy
> to work around it.
If I understand correctly all that, I agree with the 2 parts from your
comment made elsewhere:
It would be good to reach agreement on whether replacement packages
should be made public. I haven't thought much about it, so I don't know
what the relevant issues are.
<https://yhetil.org/guix/877dlxjwri.fsf@netris.org>
> How about changing "guix package -A" and "guix package -s" to display
> information about the package's replacement, if it has one?
The real question seems about ’replacement’ with upgraded version,
because otherwise it is already the expected behaviour, I mean the
behaviour that I personally expect. :-)
--8<---------------cut here---------------start------------->8---
$ guix build python
/gnu/store/wbci0x7f1q3k8rrc8d5qcckh59vl5zld-python-3.8.2
/gnu/store/r9f2bbavkbj17h2djjild5v5rd6yymcv-python-3.8.2-tk
$ guix build python --no-grafts
/gnu/store/rz42ba0my9vrgbkjpkzr2drmnjk5ah50-python-3.8.2
/gnu/store/r61fm38x5zwfaval9nf7ax960qmgsixf-python-3.8.2-tk
$ guix show python | recsel -p name,version
name: python
version: 3.8.2
outputs: out tk
--8<---------------cut here---------------end--------------->8---
> Alternatively, those commands could somehow explicitly indicate that the
> package has been grafted, and show the version number of the
> replacement, in such a way that is less confusing to users.
That’s the issue when updating a package using ’replacement’. Is the
replaced package still visible at the CLI level? If yes, we could try
to indicate something like:
--8<---------------cut here---------------start------------->8---
$ guix search imagemagick | recsel -p name,version | head -5
name: imagemagick
version: 6.9.12-2g
name: imagemagick
version: 6.9.11-48 (grafted by 6.9.12-2g)
--8<---------------cut here---------------end--------------->8---
but I do not know if it is possible / easy. And even, there are still
clumsy behaviour as pointer above.
Cheers,
simon
next prev parent reply other threads:[~2021-03-24 10:23 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-19 9:40 imagemagick@6.9.11-48 to graft or not to graft with 6.9.12-2 Léo Le Bouter
2021-03-19 11:12 ` Julien Lepiller
2021-03-21 14:04 ` Ludovic Courtès
2021-03-22 10:53 ` zimoun
2021-03-22 16:55 ` Ludovic Courtès
2021-03-22 10:29 ` Andreas Enge
2021-03-22 21:12 ` Mark H Weaver
2021-03-23 13:34 ` Léo Le Bouter
2021-03-23 17:42 ` Leo Famulari
2021-03-23 14:07 ` Ludovic Courtès
2021-03-23 23:32 ` Mark H Weaver
2021-03-23 14:22 ` Andreas Enge
2021-03-23 14:38 ` Léo Le Bouter
2021-03-23 17:45 ` Leo Famulari
2021-03-23 23:05 ` Mark H Weaver
2021-03-24 4:12 ` Leo Famulari
2021-03-23 23:42 ` Mark H Weaver
2021-03-24 10:15 ` zimoun [this message]
2021-03-27 15:48 ` Andreas Enge
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86czvohn86.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--cc=andreas@enge.fr \
--cc=guix-devel@gnu.org \
--cc=mhw@netris.org \
/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 external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.