On Wed, Jul 20, 2022 at 5:38 PM Demi Marie Obenour
<demioben...@gmail.com> wrote:
>
> On 7/19/22 08:04, Richard Shaw wrote:
> > On Tue, Jul 19, 2022 at 4:32 AM Vitaly Zaitsev via devel <
> > devel@lists.fedoraproject.org> 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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
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@lists.fedoraproject.org
Do not reply to spam on the list, report it:
https://pagure.io/fedora-infrastructure
