On Fri, Jul 22 2022, 07:16:59 PM +0200
Maxime Devos wrote:
> On 22-07-2022 19:12, kiasoc5 wrote:
> > We could have packages recommend other packages to make this
> > discovery easier for users, like Arch's opt-depends.
>
> This sounds like my previous proposal to me:
>
> > Alternatively, packages could have an additional set of inputs
> > (development-inputs?) for this use case, only added for "guix shell
> > -D" and "guix environment", though then the build environment and
> > "guix shell -D the-package" would diverge further.
> except it has a more precise semantics than Arch's, or did you have
> something different in mind?
To me as a user, "guix shell -D package" means "install everything to
/build/ the package" and "guix shell package" means "install everything
to /use/ the package". We could make it even more granular:
1. Minimal dependencies for build time (native-inputs)
2. Maximal dependencies for build time (development-inputs)
3. Minimal dependencies for runtime (inputs + propagated-inputs)
4. Maximal dependencies for runtime (optdepends)
Deciding what is minimal/maximal is the issue. For instance should we
build manpages, which might pull in more dependencies (Crux omits them)?
Should we compile with every optional flag enabled, which also
might pull in more dependencies (like Arch)? Perhaps a policy or
standard would be helpful to decide how much we need, if we need more
levels of distinction.
