Re: Rethinking propagated inputs?

[Maxime Devos <maximedevos@telenet.be>]

[-- Attachment #1: Type: text/plain, Size: 3588 bytes --]

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.

> " 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---
> 
> 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.)

I.e., something like:

  (define glib
    (package
      (name "glib")
      (outputs '("out" ; everything
                 "bin" ; glib-mkenums ... depends on Python
                 "build")) ; glib-2.0.pc
      (propagated-inputs
        `(("pcre" ,pcre #:propagate-for-output "build") ; in the Requires.private field of glib-2.0.pc
          ("libffi" ,libffi #:propagate-for-output "build") ; ditto, for gobject-2.0.pc
          ;; etc.
          ))
      (native-inputs '()) ; not relevant to this e-ail
      ...))

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. 

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]