[bug#65550] Don't add propagated-inputs for all outputs

[Maxim Cournoyer <maxim.cournoyer@gmail.com>]

Hi Liliana and 宋文武,

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

> Am Samstag, dem 26.08.2023 um 21:53 +0800 schrieb iyzsong@envs.net:
>> From: 宋文武 <iyzsong@member.fsf.org>
>>
>> * guix/profiles.scm (package->manifest-entry): Only include
>> propagated inputs from a package for its "dev" output, or its "out"
>> output if the package doesn't have a "dev" one.
>> ---
> I think this patch misses the most obvious use case of the out:lib
> split.  I also think that hardcoding this list is bound to fail.
>
> Instead, we could for the time being solve this with yet another
> package property.
>   '((propagate-inputs-from "lib")) ; but not out
>   '((propagate-inputs-from . ("lib"))) ; same meaning, different style
>   '((propagate-inputs-from "out" "lib")) ; but not doc
> If the property is missing, we still propagate from all outputs, as is
> currently done.

I'm rather against the proposed changes as it stands.  I think it'd lead
to a lot of noise in the code base and favor more complex splits of
packages, which I'm doubtful is worth the cost (in terms of
hackiness/complexity).

Since I've known Guix, I've appreciated that a simple 'find $(guix build
some-package) typically shows me the package whole, except perhaps for
its doc and debug symbols.  Having to know which packages have a "lib"
outputs when using them in package definitions is also not fun in my
experience (you start by adding the package, then it fails, then you
verify its outputs, then you add `(,package "lib")), and I fear going to
a "dev" output would bring the same kind of annoyance but at larger
scale.

I think we'd need to evaluate what we'd gain in terms of size reduction
a bit more carefully before moving in this direction and how it'd impact
the user experience.  E.g., if we can reduce the minimal Guix image size
by maybe 30%, that'd be nice, but if we're talking of about 5% like in
your example profile, it doesn't seem worth the complexity to me.

-- 
Thanks,
Maxim