Re: guix.el & multiple outputs

[Taylan Ulrich Bayirli/Kammer <taylanbayirli@gmail.com>]

ludo@gnu.org (Ludovic Courtès) writes:

> Are you suggesting that it should instead show it as two lines?
>
>   gcc-toolchain        4.9.1      out      yes   Complete GCC tool chain for C/C++ development
>   gcc-toolchain        4.9.1      debug    yes   Complete GCC tool chain for C/C++ development
>
> I think I would prefer it.  (One advantage is that it would allow users
> to mark just one specific output, which is not currently possible.)

Indeed, it lifts the whole need for separate key-bindings to choose a
non-standard output.  Can't think of any downsides either; maybe just
making the list longer.

> Conceptually, this is similar to the distinction between “binary”
> packages and “source” packages in distros like Debian.
>
> Technically, the main reason why things are this way is that in most
> cases it’s not possible to have separate build processes (and thus
> separate <package> objects) producing the various outputs, in part
> because byproducts contain hard-coded file names, which makes them
> non-relocatable.
>
> An obvious example is the “debug” output.  Another is packages that
> produce both shared libraries and programs linked against those libs:
> what shared lib would appear in the RUNPATH of the executables?

Thanks for the explanation. :)

So as I understand it, while it would be possible --in an "everything is
possible" sense-- to change the system in such a way that separate
<package>s would use the same build process, the effort/benefit ratio is
too bad.

In that case, let me just mention a concrete annoyance I had which could
be fixed on the UI side: I find it useful to keep a plain text list of
all installed packages, in a format that can also be fed back in.  So
far I used "guix package -I | awk '{print $1}'", but that doesn't handle
outputs.  A little AWK hackery could do it, but parsing that output is
probably wrong to begin with.  Maybe a --machine-readable flag could be
added, which would ideally list alternate outputs in the foo:bar format
so they can directly be fed back in.

Taylan