Hi, Am Montag, den 06.09.2021, 14:07 -0400 schrieb Maxim Cournoyer: > Hello, > > Liliana Marie Prikler <liliana.prik...@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
