On Wed, Jul 20, 2022 at 5:38 PM Demi Marie Obenour <demiobenour@xxxxxxxxx> wrote: > > On 7/19/22 08:04, Richard Shaw wrote: > > On Tue, Jul 19, 2022 at 4:32 AM Vitaly Zaitsev via devel < > > devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > > >> On 19/07/2022 01:28, Miro Hrončok wrote: > >>> I see https://bodhi.fedoraproject.org/updates/FEDORA-2022-ee990d1f61 > >> was > >>> pushed with just a handful of builds, while many others are broken. What > >>> happened here? > >> > >> Maintainers had 1 week to rebuild all their packages. Most did nothing. > >> Blame them, not me. > >> > >> I did my best: announced it in ML, waited 1 week, asked for the > >> provenpackager assistance multiple times both in ML and IRC/Matrix. No > >> one volunteered to help me. > >> > > > > Unfortunately it's very difficult to "coordinate" things like this with a > > worldwide community. Someone / somewhere is always "holiday" or "summer > > vacation", or in my case last week was my son's summer camp. In reality, a > > week really isn't enough time but we can't have stuff like this going on > > for months either so if you maintain a package that has a large number of > > dependencies it may be time to work on becoming a proven packager so you > > can at least rebuild other packages or apply "easy" fixes. > > I wonder if Fedora should have a way of saying “this release breaks > ABI, rebuild all dependent packages automatically”. This would allow > dynamic linking of Rust and Haskell programs, which have no stable > ABI at all. Bodhi or koji would rebuild all dependent packages and > push them out (following the usual testing process) without the need > for any intervention by those packages’ maintainers. Speaking for Rust: This might seem like a good idea at first, but no, this won't work at all. 1) Building a shared Rust library ("dylib" crate type, as opposed to the "cdylib" crate type, which can be used to produce libraries with a C ABI) is an opt-in feature *at the crate / library level* that I have never seen used in our 2000+ Rust packages in Fedora. So it's basically completely untested. 2) Our packaging tools don't support this use case at all. Built Rust packages are currently noarch and source-only. 3) Rust crates can be built with different feature sets or options enabled (i.e. behaviour that's controlled by conditional compilation, not by runtime switches). We'd need to provide a shared library for every combination of enabled / disabled features, and for crates with a dozen features, that would mean building and shipping 2^12 (i.e. 4096) different libraries. For a crate with 1491 features (yes, we have one of those), that would mean building 2 ^ 1491 slightly different shared libraries (~ 10^450). That's bigger than "number of particles in the known universe" type stuff. 4) I'm pushing about a dozen updates for various Rust crates to Fedora *almost every day*. You'd need to rebuild binaries for all those library changes *and* any Rust compiler changes. Rebuilding all Rust applications that are packaged for Fedora multiple times a day just for those dependency changes would cripple Fedora build infrastructure. It *might* work for C/C++ libraries in *some* cases (i.e. where there's only ABI breaks but no API changes). So in this case, automatic rebuilds wouldn't have helped either, because of non-trivial-to-fix breaking API changes with fmt 9.0.0. Fabio _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
