Order of manifest and overlapping binaries

Order of manifest and overlapping binaries

[Greg Hogan]

I could not find documentation on this circumstance or how to resolve.
Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
can go in the $GUIX_PROFILE.

Creating a container, the latter package overshadows the former
package, as below. Unclear if this is consistent. In my manifest the
former package overshadows the latter (I'd prefer to have parallel's
parallel, but by default I have sorted the listing alphabetically). Is
there a better way to fix this?

Greg

--8<---------------cut here---------------start------------->8---
$ guix shell --container moreutils parallel which coreutils
[env]$ readlink -f `which parallel`
/gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel

guix shell --container parallel moreutils which coreutils
[env]$ readlink -f $(which parallel)
/gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
--8<---------------cut here---------------end--------------->8---

This is operating from a recent guix pull:

--8<---------------cut here---------------start------------->8---
$ guix describe
Generation 44   May 11 2023 17:02:53    (current)
  guix d6f6b57
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867
--8<---------------cut here---------------end--------------->8---

Re: Order of manifest and overlapping binaries

[Csepp]

Greg Hogan <code@greghogan.com> writes:

> I could not find documentation on this circumstance or how to resolve.
> Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
> can go in the $GUIX_PROFILE.
>
> Creating a container, the latter package overshadows the former
> package, as below. Unclear if this is consistent. In my manifest the
> former package overshadows the latter (I'd prefer to have parallel's
> parallel, but by default I have sorted the listing alphabetically). Is
> there a better way to fix this?
>
> Greg
>
> --8<---------------cut here---------------start------------->8---
> $ guix shell --container moreutils parallel which coreutils
> [env]$ readlink -f `which parallel`
> /gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel
>
> guix shell --container parallel moreutils which coreutils
> [env]$ readlink -f $(which parallel)
> /gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
> --8<---------------cut here---------------end--------------->8---
>
>
> This is operating from a recent guix pull:
>
> --8<---------------cut here---------------start------------->8---
> $ guix describe
> Generation 44   May 11 2023 17:02:53    (current)
>   guix d6f6b57
>     repository URL: https://git.savannah.gnu.org/git/guix.git
>     branch: master
>     commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867
> --8<---------------cut here---------------end--------------->8---

You could create a package that just copies the contents of moreutils
to $output, but renames some files, then include the resulting package
in your manifest.  If moreutils is not propagated from any other
package, then you don't even have to do an input rewrite.

Re: Order of manifest and overlapping binaries

[Greg Hogan]

On Tue, May 16, 2023 at 4:55 PM Csepp <raingloom@riseup.net> wrote:
>
>
> Greg Hogan <code@greghogan.com> writes:
>
> > I could not find documentation on this circumstance or how to resolve.
> > Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
> > can go in the $GUIX_PROFILE.
> >
> > Creating a container, the latter package overshadows the former
> > package, as below. Unclear if this is consistent. In my manifest the
> > former package overshadows the latter (I'd prefer to have parallel's
> > parallel, but by default I have sorted the listing alphabetically). Is
> > there a better way to fix this?
> >
> > Greg
> >
> > --8<---------------cut here---------------start------------->8---
> > $ guix shell --container moreutils parallel which coreutils
> > [env]$ readlink -f `which parallel`
> > /gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel
> >
> > guix shell --container parallel moreutils which coreutils
> > [env]$ readlink -f $(which parallel)
> > /gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
> > --8<---------------cut here---------------end--------------->8---
> >
> >
> > This is operating from a recent guix pull:
> >
> > --8<---------------cut here---------------start------------->8---
> > $ guix describe
> > Generation 44   May 11 2023 17:02:53    (current)
> >   guix d6f6b57
> >     repository URL: https://git.savannah.gnu.org/git/guix.git
> >     branch: master
> >     commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867
> > --8<---------------cut here---------------end--------------->8---
>
> You could create a package that just copies the contents of moreutils
> to $output, but renames some files, then include the resulting package
> in your manifest.  If moreutils is not propagated from any other
> package, then you don't even have to do an input rewrite.

I'm still cutting my teeth on Scheme, and this looks like a simple
error, but the following from my manifest results in the error below.
The function accepts a package to inherit from and a list of files to
rename by appending the package name. This works if I change to pass
in a single string and create the list within the for-each argument.

(define (rename-files parent-package files)
  (package/inherit parent-package
    (arguments
     (substitute-keyword-arguments (package-arguments parent-package)
       ((#:phases phases #~%standard-phases)
         #~(modify-phases #$phases
             (add-after 'install 'rename-files
               (lambda* (#:key outputs #:allow-other-keys)
                 (let ((out #$output) (name #$(package-name parent-package)))
                   (for-each
                     (lambda (file)
                       (rename-file (string-append out "/" file)
                                    (string-append out "/" file "-" name)))
                     #$files))))))))))

(define moreutils-decollide
  (rename-files moreutils (list "bin/parallel")))

--8<---------------cut here---------------start------------->8---
starting phase `rename-files'
error: in phase 'rename-files': uncaught exception:
wrong-type-arg #f "Wrong type to apply: ~S" ("bin/parallel") ("bin/parallel")
phase `rename-files' failed after 0.0 seconds
Backtrace:
           9 (primitive-load "/gnu/store/qrj9l194a552vpg2234xx55k76j…")
In guix/build/gnu-build-system.scm:
    908:2  8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
In ice-9/boot-9.scm:
  1752:10  7 (with-exception-handler _ _ #:unwind? _ # _)
In srfi/srfi-1.scm:
    634:9  6 (for-each #<procedure 7ffff5b0b140 at guix/build/gnu-b…> …)
In ice-9/boot-9.scm:
  1752:10  5 (with-exception-handler _ _ #:unwind? _ # _)
In guix/build/gnu-build-system.scm:
   929:23  4 (_)
In ice-9/eval.scm:
    159:9  3 (_ #(#(#(#<directory (guile-user) 7ffff77f7c80>) (#)) …))
    159:9  2 (_ _)
In ice-9/boot-9.scm:
  1685:16  1 (raise-exception _ #:continuable? _)
  1685:16  0 (raise-exception _ #:continuable? _)

ice-9/boot-9.scm:1685:16: In procedure raise-exception:
Wrong type to apply: "bin/parallel"
--8<---------------cut here---------------end--------------->8---

Re: Order of manifest and overlapping binaries

[Kaelyn]

Hi,

------- Original Message -------
On Monday, October 23rd, 2023 at 6:18 AM, Greg Hogan <code@greghogan.com> wrote:

> 
> On Tue, May 16, 2023 at 4:55 PM Csepp raingloom@riseup.net wrote:
> 
> > Greg Hogan code@greghogan.com writes:
> > 
> > > I could not find documentation on this circumstance or how to resolve.
> > > Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
> > > can go in the $GUIX_PROFILE.
> > > 
> > > Creating a container, the latter package overshadows the former
> > > package, as below. Unclear if this is consistent. In my manifest the
> > > former package overshadows the latter (I'd prefer to have parallel's
> > > parallel, but by default I have sorted the listing alphabetically). Is
> > > there a better way to fix this?
> > > 
> > > Greg
> > > 
> > > --8<---------------cut here---------------start------------->8---
> > > $ guix shell --container moreutils parallel which coreutils
> > > [env]$ readlink -f `which parallel`
> > > /gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel
> > > 
> > > guix shell --container parallel moreutils which coreutils
> > > [env]$ readlink -f $(which parallel)
> > > /gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
> > > --8<---------------cut here---------------end--------------->8---
> > > 
> > > This is operating from a recent guix pull:
> > > 
> > > --8<---------------cut here---------------start------------->8---
> > > $ guix describe
> > > Generation 44 May 11 2023 17:02:53 (current)
> > > guix d6f6b57
> > > repository URL: https://git.savannah.gnu.org/git/guix.git
> > > branch: master
> > > commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867
> > > --8<---------------cut here---------------end--------------->8---
> > 
> > You could create a package that just copies the contents of moreutils
> > to $output, but renames some files, then include the resulting package
> > in your manifest. If moreutils is not propagated from any other
> > package, then you don't even have to do an input rewrite.
> 
> 
> I'm still cutting my teeth on Scheme, and this looks like a simple
> error, but the following from my manifest results in the error below.
> The function accepts a package to inherit from and a list of files to
> rename by appending the package name. This works if I change to pass
> in a single string and create the list within the for-each argument.
> 
> (define (rename-files parent-package files)
> (package/inherit parent-package
> (arguments
> (substitute-keyword-arguments (package-arguments parent-package)
> ((#:phases phases #~%standard-phases)
> #~(modify-phases #$phases
> (add-after 'install 'rename-files
> (lambda* (#:key outputs #:allow-other-keys)
> (let ((out #$output) (name #$(package-name parent-package)))
> (for-each
> (lambda (file)
> (rename-file (string-append out "/" file)
> (string-append out "/" file "-" name)))
> #$files))))))))))
> 
> (define moreutils-decollide
> (rename-files moreutils (list "bin/parallel")))
> 
> --8<---------------cut here---------------start------------->8---
> 
> starting phase `rename-files' error: in phase 'rename-files': uncaught exception: wrong-type-arg #f "Wrong type to apply: ~S" ("bin/parallel") ("bin/parallel") phase` rename-files' failed after 0.0 seconds

This error is because using gexps adds an extra layer of expansion on top of normal scheme. The error is coming from the use of "#$files"... specifically in the subform "(for-each (lambda (file) ...) #$files)", #$files is replaced--in the usage example--with exactly ("bin/parallel"), resulting in:
   (for-each (lambda (file) ...) ("bin/parallel"))

Because it is a gexp, #$file is replaced with ("bin/parallel") and then the resulting form is evaluated on the builder. Since ("bin/parallel") now looks like a function call, it tries to treat it as one. The three main options that I know of are to
1) quote the argument when calling rename-files so that "list" is first in the literal list:
    (rename-files moreutils '(list "bin/parallel"))
2) quote the list within the gexp:
    (for-each (lambda (file) ...) '#$files)
3) build the list within the gexp:
    (for-each (lambda (file) ...) (list #@$files)

In my opinion the second option is probably the easiest and safest to work with. #1 and #3 both suffer from needing to specially craft the incoming argument to handle being evaluated twice. For #1, the argument has to be a list after being evaluated twice (the first evaluation is of the quote, the second occurs after the gexp was expanded and calls list with the string arguments). For #3, the expectation of a list is more explicit, but the argument has to evaluate to a list where all of the elements have to then evaluate to something meaningful (not too much of an issue for this case as strings evaluate to themselves). #2 should only require that the evaluated argument has a printable representation that can be read back in, which at least to me feels more natural to work with.

Hope my early morning explanation helps!

Cheers,
Kaelyn

> Backtrace:
> 9 (primitive-load "/gnu/store/qrj9l194a552vpg2234xx55k76j…")
> In guix/build/gnu-build-system.scm:
> 908:2 8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
> In ice-9/boot-9.scm:
> 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _)
> In srfi/srfi-1.scm:
> 634:9 6 (for-each #<procedure 7ffff5b0b140 at guix/build/gnu-b…> …)
> 
> In ice-9/boot-9.scm:
> 1752:10 5 (with-exception-handler _ _ #:unwind? _ # )
> In guix/build/gnu-build-system.scm:
> 929:23 4 ()
> In ice-9/eval.scm:
> 159:9 3 (_ #(#(#(#<directory (guile-user) 7ffff77f7c80>) (#)) …))
> 
> 159:9 2 (_ _)
> In ice-9/boot-9.scm:
> 1685:16 1 (raise-exception _ #:continuable? _)
> 1685:16 0 (raise-exception _ #:continuable? _)
> 
> ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> Wrong type to apply: "bin/parallel"
> --8<---------------cut here---------------end--------------->8---

Re: Order of manifest and overlapping binaries

[Greg Hogan]

On Mon, Oct 23, 2023 at 10:39 AM Kaelyn <kaelyn.alexi@protonmail.com> wrote:
>
> Hi,
>
> ------- Original Message -------
> On Monday, October 23rd, 2023 at 6:18 AM, Greg Hogan <code@greghogan.com> wrote:
>
> >
> > On Tue, May 16, 2023 at 4:55 PM Csepp raingloom@riseup.net wrote:
> >
> > > Greg Hogan code@greghogan.com writes:
> > >
> > > > I could not find documentation on this circumstance or how to resolve.
> > > > Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
> > > > can go in the $GUIX_PROFILE.
> > > >
> > > > Creating a container, the latter package overshadows the former
> > > > package, as below. Unclear if this is consistent. In my manifest the
> > > > former package overshadows the latter (I'd prefer to have parallel's
> > > > parallel, but by default I have sorted the listing alphabetically). Is
> > > > there a better way to fix this?
> > > >
> > > > Greg
> > > >
> > > > --8<---------------cut here---------------start------------->8---
> > > > $ guix shell --container moreutils parallel which coreutils
> > > > [env]$ readlink -f `which parallel`
> > > > /gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel
> > > >
> > > > guix shell --container parallel moreutils which coreutils
> > > > [env]$ readlink -f $(which parallel)
> > > > /gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
> > > > --8<---------------cut here---------------end--------------->8---
> > > >
> > > > This is operating from a recent guix pull:
> > > >
> > > > --8<---------------cut here---------------start------------->8---
> > > > $ guix describe
> > > > Generation 44 May 11 2023 17:02:53 (current)
> > > > guix d6f6b57
> > > > repository URL: https://git.savannah.gnu.org/git/guix.git
> > > > branch: master
> > > > commit: d6f6b57766e95d2fa8af63d4460a2b303ca4d867
> > > > --8<---------------cut here---------------end--------------->8---
> > >
> > > You could create a package that just copies the contents of moreutils
> > > to $output, but renames some files, then include the resulting package
> > > in your manifest. If moreutils is not propagated from any other
> > > package, then you don't even have to do an input rewrite.
> >
> >
> > I'm still cutting my teeth on Scheme, and this looks like a simple
> > error, but the following from my manifest results in the error below.
> > The function accepts a package to inherit from and a list of files to
> > rename by appending the package name. This works if I change to pass
> > in a single string and create the list within the for-each argument.
> >
> > (define (rename-files parent-package files)
> > (package/inherit parent-package
> > (arguments
> > (substitute-keyword-arguments (package-arguments parent-package)
> > ((#:phases phases #~%standard-phases)
> > #~(modify-phases #$phases
> > (add-after 'install 'rename-files
> > (lambda* (#:key outputs #:allow-other-keys)
> > (let ((out #$output) (name #$(package-name parent-package)))
> > (for-each
> > (lambda (file)
> > (rename-file (string-append out "/" file)
> > (string-append out "/" file "-" name)))
> > #$files))))))))))
> >
> > (define moreutils-decollide
> > (rename-files moreutils (list "bin/parallel")))
> >
> > --8<---------------cut here---------------start------------->8---
> >
> > starting phase `rename-files' error: in phase 'rename-files': uncaught exception: wrong-type-arg #f "Wrong type to apply: ~S" ("bin/parallel") ("bin/parallel") phase` rename-files' failed after 0.0 seconds
>
> This error is because using gexps adds an extra layer of expansion on top of normal scheme. The error is coming from the use of "#$files"... specifically in the subform "(for-each (lambda (file) ...) #$files)", #$files is replaced--in the usage example--with exactly ("bin/parallel"), resulting in:
>    (for-each (lambda (file) ...) ("bin/parallel"))
>
> Because it is a gexp, #$file is replaced with ("bin/parallel") and then the resulting form is evaluated on the builder. Since ("bin/parallel") now looks like a function call, it tries to treat it as one. The three main options that I know of are to
> 1) quote the argument when calling rename-files so that "list" is first in the literal list:
>     (rename-files moreutils '(list "bin/parallel"))
> 2) quote the list within the gexp:
>     (for-each (lambda (file) ...) '#$files)
> 3) build the list within the gexp:
>     (for-each (lambda (file) ...) (list #@$files)
>
> In my opinion the second option is probably the easiest and safest to work with. #1 and #3 both suffer from needing to specially craft the incoming argument to handle being evaluated twice. For #1, the argument has to be a list after being evaluated twice (the first evaluation is of the quote, the second occurs after the gexp was expanded and calls list with the string arguments). For #3, the expectation of a list is more explicit, but the argument has to evaluate to a list where all of the elements have to then evaluate to something meaningful (not too much of an issue for this case as strings evaluate to themselves). #2 should only require that the evaluated argument has a printable representation that can be read back in, which at least to me feels more natural to work with.
>
> Hope my early morning explanation helps!
>
> Cheers,
> Kaelyn
>
> > Backtrace:
> > 9 (primitive-load "/gnu/store/qrj9l194a552vpg2234xx55k76j…")
> > In guix/build/gnu-build-system.scm:
> > 908:2 8 (gnu-build #:source _ #:outputs _ #:inputs _ #:phases . #)
> > In ice-9/boot-9.scm:
> > 1752:10 7 (with-exception-handler _ _ #:unwind? _ # _)
> > In srfi/srfi-1.scm:
> > 634:9 6 (for-each #<procedure 7ffff5b0b140 at guix/build/gnu-b…> …)
> >
> > In ice-9/boot-9.scm:
> > 1752:10 5 (with-exception-handler _ _ #:unwind? _ # )
> > In guix/build/gnu-build-system.scm:
> > 929:23 4 ()
> > In ice-9/eval.scm:
> > 159:9 3 (_ #(#(#(#<directory (guile-user) 7ffff77f7c80>) (#)) …))
> >
> > 159:9 2 (_ _)
> > In ice-9/boot-9.scm:
> > 1685:16 1 (raise-exception _ #:continuable? _)
> > 1685:16 0 (raise-exception _ #:continuable? _)
> >
> > ice-9/boot-9.scm:1685:16: In procedure raise-exception:
> > Wrong type to apply: "bin/parallel"
> > --8<---------------cut here---------------end--------------->8---

Kaelyn,

Thank you for the detailed explanation. I went with #2 as recommended.
  https://github.com/greghogan/guix-manifest/blob/main/manifest/library.scm#L33

Greg

Re: Order of manifest and overlapping binaries

[Attila Lendvai]

> I could not find documentation on this circumstance or how to resolve.
> Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
> can go in the $GUIX_PROFILE.


i have proposed a solution for a special case of this problem: to do alphanumeric sorting, which together with semantic versioning picks the latest from the collisions of different versions of the same package.

see: https://issues.guix.gnu.org/50878#12

the cleanup commits reached master by now, but the actual change of the semantics of the union has not. it needs to be revived/rebased.

in its current form it wouldn't help in your case, but it points to the relevant part of the codebase.

HTH,

--
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“In a country where the sole employer is the State, opposition means death by slow starvation. The old principle: who does not work does not eat, has been replaced by a new one: who does not obey shall not eat.”
	— Leon Trotsky

Re: Order of manifest and overlapping binaries

[John Kehayias]

[-- Attachment #1: Type: text/plain, Size: 1384 bytes --]

See also https://issues.guix.gnu.org/58859 and linked issues (some already mentioned and most authors on this thread are involved in some/all of these issue reports). I think this all points to the need for some fixes and/or clarity here for the user.

(apologies for the top post and formatting while I'm away from a proper computer)
-------- Original Message --------
On May 17, 2023, 4:23 AM, Attila Lendvai wrote:

>> I could not find documentation on this circumstance or how to resolve. > Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one > can go in the $GUIX_PROFILE. i have proposed a solution for a special case of this problem: to do alphanumeric sorting, which together with semantic versioning picks the latest from the collisions of different versions of the same package. see: https://issues.guix.gnu.org/50878#12 the cleanup commits reached master by now, but the actual change of the semantics of the union has not. it needs to be revived/rebased. in its current form it wouldn't help in your case, but it points to the relevant part of the codebase. HTH, -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “In a country where the sole employer is the State, opposition means death by slow starvation. The old principle: who does not work does not eat, has been replaced by a new one: who does not obey shall not eat.” — Leon Trotsky

[-- Attachment #2: Type: text/html, Size: 1545 bytes --]

Re: Order of manifest and overlapping binaries

[Simon Tournier]

Hi,

On Tue, 16 May 2023 at 16:41, Greg Hogan <code@greghogan.com> wrote:

> I could not find documentation on this circumstance or how to resolve.
> Both 'parallel' and 'moreutils' produce a 'bin/parallel' and only one
> can go in the $GUIX_PROFILE.
>
> Creating a container, the latter package overshadows the former
> package, as below. Unclear if this is consistent. In my manifest the
> former package overshadows the latter (I'd prefer to have parallel's
> parallel, but by default I have sorted the listing alphabetically). Is
> there a better way to fix this?
>
> --8<---------------cut here---------------start------------->8---
> $ guix shell --container moreutils parallel which coreutils
> [env]$ readlink -f `which parallel`
> /gnu/store/xd9kbadmrrbpkjs9vl1v9rhgayfxwgbc-parallel-20230422/bin/parallel
>
> guix shell --container parallel moreutils which coreutils
> [env]$ readlink -f $(which parallel)
> /gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
> --8<---------------cut here---------------end--------------->8---

Command-line is parsed from right to left.  Therefore, it is consistent.

However, when using manifest, it is parsed from left to right.  See
#43585 [1].  Compare:

--8<---------------cut here---------------start------------->8---
$ cat moreutils-parallel.scm
(specifications->manifest
 (list "moreutils" "parallel"))

$ guix shell -C -m moreutils-parallel.scm coreutils which
[env]$ readlink -f $(which parallel)
/gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel

$ guix shell -C moreutils parallel coreutils which
[env]$ readlink -f $(which parallel)
/gnu/store/wi3j9z1s5pdna43ccyjf6c5pa1gnpg4x-parallel-20230622/bin/parallel
--8<---------------cut here---------------end--------------->8---

versus

--8<---------------cut here---------------start------------->8---
$ cat parallel-moreutils.scm
(specifications->manifest
 (list "parallel" "moreutils"))

$ guix shell -C -m parallel-moreutils.scm coreutils which
[env]$ readlink -f $(which parallel)
/gnu/store/wi3j9z1s5pdna43ccyjf6c5pa1gnpg4x-parallel-20230622/bin/parallel

$ guix shell -C parallel moreutils coreutils which
[env]$ readlink -f $(which parallel)
/gnu/store/60zdm9zm0nqm5d97vs30sf4plb2ib5p9-moreutils-0.67/bin/parallel
--8<---------------cut here---------------end--------------->8---

Well, I do not know if it is a feature or a bug. :-)

Especially when command-lines are not all consistent.

--8<---------------cut here---------------start------------->8---
$ guix show moreutils parallel | recsel -Cp name
name: moreutils
name: parallel

$ guix show parallel moreutils | recsel -Cp name
name: parallel
name: moreutils
--8<---------------cut here---------------end--------------->8---


Cheers,
simon


1: https://issues.guix.gnu.org/43585#2