| Message ID | cover.1636898737.git.efraim@flashner.co.il |
|---|---|
| Headers | show |
| Series | Add librsvg-bootstrap | expand |
Hi, Am Sonntag, den 14.11.2021, 16:07 +0200 schrieb Efraim Flashner: > librsvg is an input for emacs, gtk+@2 and gtk+@3. With the rust > inputs this leads to (unknown) rust libraries causing the rebuild of > over 3000 packages on core-updates-frozen. Rather than hunt them down > I tracked down the packages which would have many rebuilds and added > a copy of librsvg for them to use. In my opinion, one of the selling points of Guix is that of bootstrappability. I don't think adding big blobs to Emacs of all things is a great way of delivering on that promise. I think we ought to rather "invest" in alternatives to Rust and Rust-locked libraries or make Rust packaging itself sane (if it can at all). I think librsvg is optional already and people who want to save on compilation time can decide to replace it with e.g. GNU hello using the --input option. In the similar case of mozjs, a replacement with duktape is discussed on guix-devel, at least for polkit. As a temporary resolution to the rebuild issue, we could pin the dependencies of librsvg to some specific versions and only bump them when something awful happens. I'm not sure whether librsvg exposes any of the Rust nastiness to its dependencies, ideally hoping that it would not. WDYT?
On Sun, Nov 14, 2021 at 06:27:02PM +0100, Liliana Marie Prikler wrote: > Hi, > > Am Sonntag, den 14.11.2021, 16:07 +0200 schrieb Efraim Flashner: > > librsvg is an input for emacs, gtk+@2 and gtk+@3. With the rust > > inputs this leads to (unknown) rust libraries causing the rebuild of > > over 3000 packages on core-updates-frozen. Rather than hunt them down > > I tracked down the packages which would have many rebuilds and added > > a copy of librsvg for them to use. > In my opinion, one of the selling points of Guix is that of > bootstrappability. I don't think adding big blobs to Emacs of all > things is a great way of delivering on that promise. I think we ought > to rather "invest" in alternatives to Rust and Rust-locked libraries or > make Rust packaging itself sane (if it can at all). > > I think librsvg is optional already and people who want to save on > compilation time can decide to replace it with e.g. GNU hello using the > --input option. In the similar case of mozjs, a replacement with > duktape is discussed on guix-devel, at least for polkit. It seems I was wrong about emacs; both emacs-minimal and emacs-no-x are built without librsvg. > As a temporary resolution to the rebuild issue, we could pin the > dependencies of librsvg to some specific versions and only bump them > when something awful happens. I'm not sure whether librsvg exposes any > of the Rust nastiness to its dependencies, ideally hoping that it would > not. I don't believe librsvg exposes any rust-y stuff. > WDYT? (ins)efraim@3900XT /tmp/librsvg-2.50.7$ ls vendor/ | wc -l 226 There are 226 crates that upstream bundles with their source. I suppose we could pare it down to about 200 by careful pruning but it's part of librsvg and not going away. (ins)efraim@3900XT ~/workspace/guix-core-updates$ git grep \,librsvg | wc -l 103 I'm suggesting that for gtk+@2 and gtk+@3 we use the bundled crates and for the other 101 packages we continue to use our current version, where we replace all of the bundled crates with our own copies, which get updated more often than librsvg does. With our current rust tooling I don't think it'd be that easy to find the ~226 crates that librsvg depends on, and it wouldn't be great to lock them due to librsvg being an input for gtk2/3.
Hi, Am Sonntag, den 14.11.2021, 20:07 +0200 schrieb Efraim Flashner: > > As a temporary resolution to the rebuild issue, we could pin the > > dependencies of librsvg to some specific versions and only bump > > them something awful happens. I'm not sure whether librsvg > > exposes any of the Rust nastiness to its dependencies, ideally > > hoping that it would not. > > I don't believe librsvg exposes any rust-y stuff. That sounds like a good start for once. > > WDYT? > > (ins)efraim@3900XT /tmp/librsvg-2.50.7$ ls vendor/ | wc -l > 226 > > There are 226 crates that upstream bundles with their source. I > suppose we could pare it down to about 200 by careful pruning but > it's part of librsvg and not going away. Well, I'd suggest snippeting them away, but that's a different topic. > (ins)efraim@3900XT ~/workspace/guix-core-updates$ git grep \,librsvg > | wc -l > 103 I'd hazard a guess that most if not all of these 103 packages are themselves gtk-adjacent, so what really is the issue we're solving here? What is the point of maintaining an extra version for 101 of them when a potentially vulnerable GTK sits right next to them? > I'm suggesting that for gtk+@2 and gtk+@3 we use the bundled crates > and for the other 101 packages we continue to use our current > version, where we replace all of the bundled crates with our own > copies, which get updated more often than librsvg does. > > With our current rust tooling I don't think it'd be that easy to find > the ~226 crates that librsvg depends on, and it wouldn't be great to > lock them due to librsvg being an input for gtk2/3. Said input exists due to gdk-pixbuf+svg, with the +svg part being largely optional – the most common failure mode of it not being included are broken button textures, which we could fix by pre- rendering images with a suitable tool, such as inkscape. We could easily do a minimal gtk[+]? without it. As for the lock, why can't we? gtk+ is already core-updates material, so it stands to reason that anything causing it to rebuild is too. Rather than push down blobs to the users because we can't deal with Rust, we should fix Rust or make it go away from the build. WDYT?
Hi Efraim, I had completely overlooked these patches, oops! Efraim Flashner <efraim@flashner.co.il> skribis: > librsvg is an input for emacs, gtk+@2 and gtk+@3. With the rust inputs > this leads to (unknown) rust libraries causing the rebuild of over 3000 > packages on core-updates-frozen. Rather than hunt them down I tracked > down the packages which would have many rebuilds and added a copy of > librsvg for them to use. [...] > I'm suggesting that for gtk+@2 and gtk+@3 we use the bundled crates and > for the other 101 packages we continue to use our current version, where > we replace all of the bundled crates with our own copies, which get > updated more often than librsvg does. > > With our current rust tooling I don't think it'd be that easy to find > the ~226 crates that librsvg depends on, and it wouldn't be great to > lock them due to librsvg being an input for gtk2/3. Yes, that’s a problem, though Liliana is right that bundling isn’t great either. I’m annoyed by this whole librsvg situation. On non-x86_64, we now depend on librsvg 2.40, the old C version, and guess what, it just works. That has me tempted to stick with 2.40 all along because these Rust problems don’t seem to have a pleasant, or even an easy solution. Now, using the proposed ‘librsvg-bootstrap’ in GTK+ looks like a lesser evil. Thoughts? Ludo’.
On Mon, Dec 06, 2021 at 01:17:47PM +0100, Ludovic Courtès wrote: > Hi Efraim, > > I had completely overlooked these patches, oops! > > Efraim Flashner <efraim@flashner.co.il> skribis: > > > librsvg is an input for emacs, gtk+@2 and gtk+@3. With the rust inputs > > this leads to (unknown) rust libraries causing the rebuild of over 3000 > > packages on core-updates-frozen. Rather than hunt them down I tracked > > down the packages which would have many rebuilds and added a copy of > > librsvg for them to use. > > [...] > > > I'm suggesting that for gtk+@2 and gtk+@3 we use the bundled crates and > > for the other 101 packages we continue to use our current version, where > > we replace all of the bundled crates with our own copies, which get > > updated more often than librsvg does. > > > > With our current rust tooling I don't think it'd be that easy to find > > the ~226 crates that librsvg depends on, and it wouldn't be great to > > lock them due to librsvg being an input for gtk2/3. > > Yes, that’s a problem, though Liliana is right that bundling isn’t great > either. > > I’m annoyed by this whole librsvg situation. On non-x86_64, we now > depend on librsvg 2.40, the old C version, and guess what, it just > works. That has me tempted to stick with 2.40 all along because these > Rust problems don’t seem to have a pleasant, or even an easy solution. > > Now, using the proposed ‘librsvg-bootstrap’ in GTK+ looks like a lesser > evil. > > Thoughts? Unbundling the rust crates is the right option, but not the easy option. With the assumption that rust-libc-0.2 is in the graph for librsvg, we add another copy named rust-libc-0.2.101 (the current version) and a comment that it only gets adjusted on core-updates or that it causes XXXX package rebuilds. On a small tangent, the work I do sometimes to try to actually have a dependency graph with the crates would only make these easier to find, not actually address the issue here. I'm not sure if it'd be better to mostly copy the packages with a new name and keep the cargo-inputs or to actually adjust the cargo-inputs->inputs and cargo-development-inputs->native-inputs so we get the dependency graph from rust-libc-0.2.101 to librsvg. I'd like to make the change but if we don't get the others changed then we effectively really have two sets of rust crates. If we have both cargo-inputs and inputs then the cargo-build-system doesn't have issues with using either type with later packages, so that might be the best option for now.
Hi Efraim, Efraim Flashner <efraim@flashner.co.il> skribis: > On a small tangent, the work I do sometimes to try to actually have a > dependency graph with the crates would only make these easier to find, > not actually address the issue here. > > I'm not sure if it'd be better to mostly copy the packages with a new > name and keep the cargo-inputs or to actually adjust the > cargo-inputs->inputs and cargo-development-inputs->native-inputs so we > get the dependency graph from rust-libc-0.2.101 to librsvg. I'd like to > make the change but if we don't get the others changed then we > effectively really have two sets of rust crates. > > If we have both cargo-inputs and inputs then the cargo-build-system > doesn't have issues with using either type with later packages, so that > might be the best option for now. Thinking out loud… would it work to change: (arguments '(#:cargo-inputs X #:cargo-development-inputs Y)) to: (native-inputs (map package-source Y)) (inputs (map package-source X)) ? Or am I just saying nonsense? Thanks, Ludo’.
On December 6, 2021 4:37:12 PM UTC, "Ludovic Courtès" <ludo@gnu.org> wrote: >Hi Efraim, > >Efraim Flashner <efraim@flashner.co.il> skribis: > >> On a small tangent, the work I do sometimes to try to actually have a >> dependency graph with the crates would only make these easier to find, >> not actually address the issue here. >> >> I'm not sure if it'd be better to mostly copy the packages with a new >> name and keep the cargo-inputs or to actually adjust the >> cargo-inputs->inputs and cargo-development-inputs->native-inputs so we >> get the dependency graph from rust-libc-0.2.101 to librsvg. I'd like to >> make the change but if we don't get the others changed then we >> effectively really have two sets of rust crates. >> >> If we have both cargo-inputs and inputs then the cargo-build-system >> doesn't have issues with using either type with later packages, so that >> might be the best option for now. > >Thinking out loud… would it work to change: > > (arguments '(#:cargo-inputs X #:cargo-development-inputs Y)) > >to: > > (native-inputs (map package-source Y)) > (inputs (map package-source X)) > >? > >Or am I just saying nonsense? > >Thanks, >Ludo’. Then we lose the transitive package sources, which is how we ended up where we are today. I can go and change the cargo-build-system to use the skip-build flag in more phases to skip them when we aren't going to be building them anyway. No need to generate cargo checksums if we're not building I think.