l...@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
