Hi Josselin and all, Josselin Poiret <d...@jpoiret.xyz> skribis:
> Maxim Cournoyer <maxim.courno...@gmail.com> writes: >> Josselin Poiret <d...@jpoiret.xyz> writes: [...] >>> 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. >> >> I don't mind too much; when we re-enable the change we should add a >> phase to the gnu-build-system automatically deleting/moving the libtool >> archives. so that we're covered. > > I agree, although we'll have to be careful since some packages might > need them if they don't use pkg-config! I’m in favor of whatever allows us to move forward more quickly, so temporarily stashing away the pkgconf changes sounds good to me. In that case, when time permits, could you push a ‘core-updates-new’ (?) branch, (partially) rebased and without the pkgconf changes, and a separate ‘wip-pkgconf’ branch? Does that seem doable to you? It would be great if you could also explain at which commit you started rebasing ‘core-updates’¹ and which method/script you used. Thanks for this thankless work! Ludo’. ¹ Ideally we’d preserve commits that predate the duplicated commits. That way, we’d also preserve signatures as well as commit references that appear in commit logs.
