Subject: Re: [bug#47539]

From: Leo Prikler <[email-masked]>
Date: Mon, 07 Jun 2021 15:33:40 +0200

Am Montag, den 07.06.2021, 15:11 +0200 schrieb Xinglu Chen:
> On Mon, Jun 07 2021, Xinglu Chen wrote:
> 
> > On Sun, Jun 06 2021, Leo Famulari wrote:
> > 
> > > On Sat, Jun 05, 2021 at 09:16:36PM +0200, Xinglu Chen wrote:
> > > > On Fri, May 21 2021, Leo Famulari wrote:
> > > > > I notice that (most of?) the new packages use native-inputs
> > > > > for their
> > > > > dependencies.
> > > > > 
> > > > > If these dependencies are used at run-time, I would propagate
> > > > > them
> > > > > instead. This way, they will be available in the build
> > > > > environment of
> > > > > packages that depend on the package that is using them, which
> > > > > matters
> > > > > for our go-build-system, where everything is built from
> > > > > scratch in each
> > > > > package. If I remember correctly, that is...
> > > > 
> > > > I am not familiar with the Go ecosystem, is there a way to tell
> > > > if a
> > > > dependency is used at runtime?
> > > 
> > > If foo requires bar, and baz depends on foo, then bar needs to be
> > > available when building baz. That is because foo will be rebuilt
> > > while
> > > building baz.
> > > 
> > > We must either propagate bar from foo, or make baz depend on it.
> > > Technically, bar is a dependency of foo, so it is correct to
> > > propagate
> > > it from foo.
> > 
> > So if A dependes on B which depends on C, and I want to build A,
> > then C
> > has to be a ‘propagated-input’ for B?  Did I get that right?
> > 
> > But if I just want to build B, should C still be a ‘propagated-
> > input’
> > for B?
> 
> Since a new version of the ‘github-cli’ package is out, I ran
> ‘./pre-inst-env guix import go -r github.com/cli/cli’ to see if it
> had
> any new dependencies.  I noticed that the Go importer put all the
> dependencies as ‘propagated-input’ instead of ‘native-input’ (which
> it
> did before).
> 
> My guess is that basically everything should be propagated?
Do cross-check with the output of the Go importer.  While there were
some modifications that we made (e.g. the safeexec thing), the Go
importer probably does "the right thing™".

Regards,
Leo