On Thu, Dec 10, 2020 at 01:55:53AM +0300, David Dashyan wrote:
Thanks! Overall, looks good to me.
In general, native-inputs are dependencies that are only used while
building the package. Typically, OpenSSL is also used at run-time, so it
probably should be a regular input. What do you think?
Propagated-inputs are dependencies that will be installed along with
your package when installing the package with e.g. `guix install
openfortivpn`. This is for situations where the dependency is needed at
run-time but for which the program lacks the ability to refer to
dependencies directly.
For example, a shell script that needs to invoke `ls` will need to find
it on $PATH. It would not be easy to automatically substitute calls to
`ls` to the full store path of `/gnu/store/...-coreutils-8.32/bin/ls`.
However, most dependencies can be regular inputs, because the built
package will refer to the full "/gnu/store/...-ppp-version/" path
wherever it needs to invoke the dependency.
So, does the package work if the openssl and ppp dependencies are just
'inputs' rather than native-inputs and propagated-inputs?
You can use `guix gc --references $(guix build openfortinet)` to see
what store references the built package has kept. These references are
literally just strings that look like filenames in /gnu/store, found by
scanning when the package build is completed. This tool can help one
decide if an input should be propagated — if the built package refers to
ppp, it likely can find it without propagation. Of course, practical
testing is still the true measure.
I hope that helps!
Is this the "home-page" of this program? Usually this field points to
the site where the project is coordinated or marketed. It may even be
the GitHub repo page.
Can you send a revised patch based on this feedback? Please don't
hesitate to ask any followup questions :)
