Re: How to manage package replacements?

[Andreas Enge <andreas@enge.fr>]

Hello,

Am Tue, Mar 28, 2023 at 12:51:30PM +0100 schrieb Christopher Baines:
> Does anyone know what needs to be done in any/every case when replacing
> a package?

I have no idea, and if the lack of reply means that nobody else does, this
is somewhat worrying ;-)

For python-pillow, I get this:
guix build: warning: ambiguous package specification `python-pillow'
guix build: warning: choosing python-pillow@9.2.0 from gnu/packages/python-xyz.scm:7705:2
Maybe it would already be helpful to also print the other location(s)
for the ambiguous package in the warning message?

The rationale is explained here:
   https://guix.gnu.org/de/manual/devel/en/guix.html#Security-Updates
Replacements work on the level of Scheme variables: Any package having
python-pillow as input will be served with python-pillow/security-fixes
instead, since we have this:
(define-public python-pillow
  (package
    (name "python-pillow")
    (version "9.2.0")
    (replacement python-pillow/security-fixes)
...
(define-public python-pillow/security-fixes
  (package-with-patches python-pillow
                        (search-patches "python-pillow-CVE-2022-45199.patch")))

Here the two packages have the same name field, which confuses the command
line interface. Hiding the first one looks like a solution, or giving them
different names "python-pillow-insecure" for the first one and
"python-pillow" for the second one, for instance, the important point being
that the second one gets the usual name. Hm, the reference to the manual
above mentions that the names must have the same length. So maybe use
"python-pilXXX" for the first one? But then it gets recompiled, which is
exactly what grafting tries to avoid. So hiding seems to be the only option.

Caeterum censeo the solution to everythig is ungrafting :-)

Andreas