Guix Jargon File (WAS: Rethinking propagated inputs?)

[Liliana Marie Prikler]

Hi,

Am Sonntag, den 05.09.2021, 11:50 +0200 schrieb Bengt Richter:
> > We don't call things build-inputs here in Guix land, that's a no-no 
> > :P
> 
> Is there an official guix jargon file or glossary file or texi file
> or wikimedia/wiktionary/wikipedia clone on gnu.org that non-
> cognoscenti could use to get a clue?
AFAIK no, you more or less have to go by what the manual tells you.  As
for why we have native-inputs and not build-inputs like other distros,
it's because people often misclassify "build" inputs, so the definition
actually does more harm than good.  Guix knows which files are actually
"just used for build" by what ends up in the store, with some
exceptions like UTF-32 encoded strings.

> Is there a thread that on that topic making any progress on making it
> happen?
AFAIK no.

> when someone in a thread like this offers a candidate official
> definition, (off-topic sort of, but meta-on-topic for relevant
> documentation) could it be snip-quoted for easy search and
> aggregation for maintainers of official definitions and translations?
> E.g.
> (or actually borrow some rfc0842 or descendant so an attached file
> generates a usuable section in mail archives that can be snarfed
> automatically?)
> 
> --8<---------------cut here---------------start------------->8---
> X-Content-type: Cadidate-guix-jargon-definition
> Ad lib comment and metacomment ended by blank line ...
> "> We don't call things build-inputs here in Guix land, that's a no-
> no :P"
> 
> build-propagated-inputs:
>       <please fill in :) >
> --8<---------------cut here---------------end--------------->8---
When you quote someone like that out-of-context, you run a risk of
misrepresenting what is actually stated.  What I mean, is that a
package field called something along the lines of "build-inputs" is
likely to confuse Guix veterans and newcomers alike, as evidenced by
the following reply:

Am Sonntag, den 05.09.2021, 10:06 +0000 schrieb Attila Lendvai:
> potentially worthless two cents from a newcomer's perspective:
> 'build-time' and 'run-time' are well established concepts in the
> wider community.
And one, that is well misunderstood.  

> if i were reading 'linked-inputs' in a package definition, i wouldn't
> associate it to being the set of build-time dependencies.
That's not what linked-inputs are, though.  Take the following
paragraph from propagated-inputs:

> For example this is necessary when packaging a C/C++ library
> that needs headers of another library to compile, or when a
> pkg-config file refers to another one via its ‘Requires’
> field.
This use case of propagated inputs explains why they need to be
propagated when given as a (propagated-)input to a package, but not
when given as a native input or merely existing in a profile.

The – required if we go by other systems – use case of installing
libraries system- or user-wide is already discouraged by Guix, for it
is not needed.  As long as we can spawn an environment, in which we can
compile these things, it should be enough.

Note, that this is not equivalent to being a "build-time" dependency. 
Going by Gentoo's definition "Build dependencies are used to specify
any dependencies that are required to unpack, patch, compile, test or
install the package", GCC is a build dependency of nearly any C program
(and a native one at that, i.e. BDEPEND in Gentoo), but it's not a
linked-dependency, because there are numerous ways in which other
programs could use it without ever needing to invoke GCC.  Guix, of
course, includes GCC as an implicit native input anyway, but that's a
different topic.

Regards