Hi everyone,

I've just cleaned up the c-u branch locally (removing all the duplicated
commits) and rebased it on master since we're going to have to rewrite
history anyways.  I'm trying to build a bit with it to double check that
nothing got messed up in the process, so I haven't pushed that anywhere
yet.

Efraim Flashner <efraim@flashner.co.il> writes:

> Seeing that librsvg has rust-pango (and some others) in cargo-inputs,
> and therefore needs pango to build, I think it's safe to move pango (and
> others as needed) to propagated inputs. Make sure to make the necessary
> changes to librsvg-2.40 also.
>
> I haven't had any problems building the rust based librsvg on
> core-updates, so I'd suggest leaving that alone for now.

Basically, the issue is that libtool+pkg-config used to overlink,
leading to libtool dependencies being fulfilled without needing them to
be actually present as inputs.  Now, because there are recent commits
replacing pkg-config with pkgconf, libtool is requiring more libraries
than needed at link time.  The option then is to just remove .la
(libtool archive) files in package outputs, so that their dependents
don't try to use them (and it usually just works).

Removing them in librsvg makes guile-rsvg build again.

However, as you can see, these are non-local failures: build failures
have to be fixed in a dependency, which incurs a lot of rebuilding.
I've fixed a couple of them locally, but here's a nasty one I just got
stuck on: curl has a .la file with "-lnettle -lhogweed -lgssapi_krb5",
which leads to a build failure for... flatpak :( So fixing this properly
would lead to a world rebuild.

I'm worried this will keep accumulating a bunch of world rebuilds,
slowing down c-u some more.  I'd vote to keep the pkgconf switch for
later and focus on merging the rest of what c-u has to offer.

WDYT?
-- 
Josselin Poiret