Rethinking propagated inputs?

[Liliana Marie Prikler]

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" and "icecat" independently, because
both propagate glib.  "libreoffice" and "telegram-desktop", two
packages that have failed us loudly before, are also in that list.  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?