Re: Rethinking propagated inputs?

[Liliana Marie Prikler]

Hi

Am Sonntag, den 05.09.2021, 18:17 +0200 schrieb Maxime Devos:
> Liliana Marie Prikler schreef op za 04-09-2021 om 20:24 [+0200]:
> > Hi Guix,
> > 
> > some while ago we made the decision to propagate inputs, that are
> > mentioned in pkg-config files, the rationale being that those
> > propagated inputs will be needed in packages in order to
> > compile.  This
> > has saved us some typing, but at a cost.  For instance, it is now
> > no
> > longer possible to upgrade "zile"
> 
> Zile doesn't propagate glib: it's in inputs, not propagated-inputs:
> https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/zile.scm#n84.
Oops, what a blunder.  It turns out my mistake was
> > " and "icecat" independently, because
> > both propagate glib.  "libreoffice" and "telegram-desktop", two
> > packages that have failed us loudly before, are also in that list.
> 
> libreoffice doesn't propagate anything.  Neither does icecat.
> 
> >   To
> > see what else is in here, you might want to use the following
> > snippet
> > in a guix repl:
> > 
> > --8<---------------cut here---------------start------------->8---
> > (use-modules (guix packages)
> >              (gnu packages)
> >              (guix discovery)
> >              (srfi srfi-1)
> >              (srfi srfi-26))
> > 
> > (display
> >  (fold-packages
> >  (lambda (p s)
> >    (if (any (compose (lambda (input)
> >                        (and (package? input)
> >                             (string=? "glib" (package-name
> > input))))
> >                      cadr)
> >             (package-transitive-inputs p))
> >        (cons (package-name p) s)
> >        s))
> >  '()
> >  (all-modules %default-package-module-path)))
> > --8<---------------cut here---------------end--------------->8---
(package-transitive-inputs p) should be (package-transitive-propagated-
inputs p).  With that, telegram-desktop is still in the list, as is
gst-plugins-base (why?), rhythmbox, polari, and some others.

> > It returns more than 1400 packages – a bit less than 10% of Guix. 
> > Needless to say, that's a bad thing and I think we should do
> > something about it, particularly when it comes to leaf packages,
> > that users are likely to install.
> > 
> > Does anyone have an idea how we should handle propagations for the
> > sake of pkg-config?  Perhaps we could add "linked-inputs", which
> > are added when building packages and environments when not using --
> > ad-hoc, but not when union-building profiles.  WDYT?
> 
> For packages using pkg-config, I had the following scheme in mind:
> 
> A package that has .pc files puts them into a separate "build"
> output.  The code handling 'propagated-inputs' is modified such that
> an entry in 'propagated-inputs' can have an additional 'propagated-
> for-output' component.
> 
> (Feel free to suggest a more concise name.)
Since "propagated" is already given by propagated-inputs, what about
simply having #:by?

E.g. something like:
  (define glib
    (package
      (name "glib")
      (outputs '("out" ; everything
                 "bin")) ; glib-mkenums ... depends on Python
      (propagated-inputs
        `(("pcre" ,pcre #:by ("out"))     ; future-proof #:by  
          ("libffi" ,libffi #:by ("out")) ; have it be a list
          [...]))

I'm not sure whether we need to necessarily add a new "build" output
for pkg-config, that'd lead to a lot of doubly-propagated includes. 
(Imagine both libffi and libffi:build etc.)  I think the more
meaningful division here would be to add "bin" or "lib" outputs to
those packages, where we don't want propagation to continue
indefinitely.  This does cause problems with language bindings though,
e.g. pygobject, as those also propagate the package in question and
can't be neatly separated.

> Now, imagine the "build" output of "zile" had glib:build in
> propagated-inputs, using the scheme described above.  Then, if the
> "out" output of zile is installed in a profile, that doesn't cause
> glib to appear in the profile as well, because glib
> is only propagated for the "build" output of zile, and not for "out"
> output of zile.
> 
> However, if "build" is installed in the profile (e.g. because someone
> runs "guix environment --ad-hoc zile:build various compilation tools"
> to create an application using the zile library), then the .pc
> becomes available in the profile. 
I must admit that this solution appears to have some surface elegance,
but what exactly would go in the "build" output of a package?  You
mentioned pkg-config files (obviously), but those don't suffice to
actually build a package, do they?  Would we need an extra syntax to
e.g. propagate the "out" output by "build" (and in some cases the "lib"
output instead)?

Greetings