Re: Rethinking propagated inputs?

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Montag, den 06.09.2021, 14:07 -0400 schrieb Maxim Cournoyer:
> Hello,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > 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.
> 
> It seems the original issue pointed at was somewhat misguided; is
> there still something to be fixed about propagated inputs?  It seems
> the discussion has moved toward handling propagated inputs for the
> use of pkg-config.
While those two examples were picked from a set, that might arguably be
too large, the point still stands that far too many packages are
propagating glib through some way or another.  Rhythmbox for instance
propagates it through dconf, Polari through telepathy-glib, and so on.

The question I've been poking at has always been that of propagating
packages mentioned by pkg-config, because that's the main reason glib
gets propagated by a bunch of related libraries.  There are some
fundamental flaws with certain software like GTKSourceView, that can't
function unless propagated by the package using it, but those are more
limited in the number of packages they affect.  There's still 355
packages somehow propagating glib (about a third of all packages
dependant on glib).

Sometimes those packages can be fixed without propagation.  For
instance, a meld bug that still exists on master would probably
disappear by applying <http://issues.guix.gnu.org/48445>, which
mentions that installing or propagating some package would also fix
this for some.

Perhaps instead of propagating packages mentioned by pkg-config, we
could symlink the required .pc files in an additional phase.  Then, as
per what Maxime Devos mentioned for "build" outputs, we would always
have the packages present in the build environment even if they're not
propagated.  WDYT?

> What are the current problems with it, and what would the advantages
> be to move away from the status quo?  If there aren't clear benefits,
> I'd prefer the status quo, abstaining from the added complexity.
The problem with propagated packages is that they devolve Guix into a
traditional distro in which you can not upgrade parts of your system
without also upgrading other parts.  This is all fine and dandy when it
affects related systems, e.g. only Emacs packages, but if two random
packages can crash because they depend on some low-level library,
that's very, very bad.  I think we should try to minimize the
occurrences of that.

Thanks