[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Design decision behind inputs/native-inputs/propagated-inputs

From: Steven Allen
Subject: Design decision behind inputs/native-inputs/propagated-inputs
Date: Wed, 20 Jan 2016 23:49:09 -0500
User-agent: Mutt/ (2014-03-12)


I just attended David Thompson's talk about Guix and asked some
questions about the difference between inputs, propagated-inputs, and
native-inputs. I believe I now understand what each does but am unclear
as to why.

Currently, I use Arch. On Arch, we have makedepends and depends where
only depends are kept at runtime. On Guix, this distinction is detected
at build time by searching the output files for references into the
inputs. However, unless I'm mistaken, native-inputs are *usually* build
dependencies and inputs are *usually* runtime dependencies. So, my
question is why not:

1. Get rid of the automagic run/build dependency detection.
2. Have:
  a. private-inputs -- runtime dependencies not linked into the environment
  b. propagated-inputs -- no change
  c. build-inputs -- always native, never included in the final output

Specifically, what is the use case for non-native build-only dependencies 
(inputs that are not included in the final package) and native runtime
dependencies (native-inputs that *are* included in the final package)?
Alternatively, am I completely missing the point?

P.S. Please CC, I'm not subscribed.

Steven Allen

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]