[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: inputs vs. native-inputs vs. propagated-inputs
From: |
Hartmut Goebel |
Subject: |
Re: inputs vs. native-inputs vs. propagated-inputs |
Date: |
Fri, 17 Jun 2016 22:49:59 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 |
Hallo Leo,
thanks for you answer.
Am 12.06.2016 um 21:53 schrieb Leo Famulari:
> 'Inputs' do typically get used at run-time, as do propagated-inputs.
>
> I found it hard to understand the distinctions by reading. It was only
> when I had been making packages for a while that I understood.
>
> I've tried to improve this text but I haven't come up with anything yet.
I'd try a text, but I did not really understand the difference yet.
>>> If so, how can I as a packager find out if eg. libBBB is only used at
>>> build time and libCCC need to be a propagated input?
> You will need at least a little knowledge about the programs you are
> packaging and how they are supposed to build and run. I read a bit about
> each program to guess about how libAAA uses it.
IC. I was hoping. I could just package some stuff without any knowledge.
E.g to make basic libraries and programs available so others can add
more programs. Obviously I was wrong here :-(
>
>> I'm the packager, so I'm the one who needs to *define* the dependencies.
>> There is no ‘guix gc –-references …’ I can query. So *I* need a way to
>> determine whether an input needs to be propagated or not.
> Test the program in an isolated environment and see if it works without
> propagating the inputs.
Thanks, this is a helpful tip.
> Also, once you've built the package, using `guix gc --references` is a
> good way to inspect it.
This is what I do not get: If I do not specify some dependency, how will
it be listed with `gc --references` (except the case there is another
dependency). And if `gc --references` would be able to find dependencies
I missed, why at all should one list dependencies?
> The type of input chosen by the packager does not dictate how libAAA
> uses the dependency. The package could erroneously retain a reference to
> a native-input like Automake, and `guix gc --references` will show you
> this.
>
> So, if libCCC appears in `guix gc --references /gnu/store/...-libAAA`,
> it's reasonable to guess that libCCC does not need to be propagated.
>
> Or, the package could lack a reference to something you *know* is needed
> at run-time. So you can address that with propagated-inputs or setting
> some build-time configuration.
>
> Is it making more sense?
It opens a window in the dust of incomprehension :-) But I need to thing
(and test) on this whole topic a lot more.
--
Regards
Hartmut Goebel
| Hartmut Goebel | address@hidden |
| www.crazy-compilers.com | compilers which you thought are impossible |
- inputs vs. native-inputs vs. propagated-inputs, Hartmut Goebel, 2016/06/12
- Re: inputs vs. native-inputs vs. propagated-inputs, 宋文武, 2016/06/12
- Re: inputs vs. native-inputs vs. propagated-inputs, Hartmut Goebel, 2016/06/12
- Re: inputs vs. native-inputs vs. propagated-inputs, Leo Famulari, 2016/06/12
- Re: inputs vs. native-inputs vs. propagated-inputs,
Hartmut Goebel <=
- Re: inputs vs. native-inputs vs. propagated-inputs, Leo Famulari, 2016/06/17
- Re: inputs vs. native-inputs vs. propagated-inputs, Ludovic Courtès, 2016/06/18
- Re: inputs vs. native-inputs vs. propagated-inputs, Lukas Gradl, 2016/06/19
- Re: inputs vs. native-inputs vs. propagated-inputs, Ludovic Courtès, 2016/06/19
- Re: inputs vs. native-inputs vs. propagated-inputs, Lukas Gradl, 2016/06/21