On 7/24/22 19:16, Fabio Valentini wrote: > On Sun, Jul 24, 2022 at 11:02 AM Demi Marie Obenour > <demiobenour@xxxxxxxxx> wrote: >> >> On 7/23/22 07:46, Fabio Valentini wrote: >>> On Sat, Jul 23, 2022 at 12:56 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: >>>> >>>> On Sat, Jul 23, 2022 at 4:14 AM Dan Čermák >>>> <dan.cermak@xxxxxxxxxxxxxxxxxxx> wrote: >>>>> >>>>> Richard Shaw <hobbes1069@xxxxxxxxx> writes: >>>>> >>>>>> Replying in general... >>>>>> >>>>>> I've asked about a "one script to rule them all" a few times over my 10+ >>>>>> year Fedora packaging career and it's fallen on deaf ears. >>>>>> >>>>>> I hope something will happen this time. There should really be only ONE way >>>>>> to determine what packages need to be rebuilt, even if it's not perfect, we >>>>>> can deal with the corner cases but everyone doing their own thing has >>>>>> definitely been worse. >>>>> >>>>> In a perfect world koji or koschei would figure this out themselves and >>>>> perform the rebuilds for us so that we can finally stop thinking about >>>>> build orders and dependencies ourselves. >>>> >>>> The sad part is that Koschei can do it, but the build system folks >>>> have so far refused to enhance Koji and Koschei to do this for >>>> creating *real builds* that are auto-submitted. >>> >>> Alright Neal, this is a bit off-topic, but I'll bite. >>> >>> Auto-submitting real builds is something that I will, except in very >>> narrowly defined exceptions, always disagree with. >>> Until now, automagic builds have only caused trouble. Just look at the >>> mess that's regularly made in the podman/container stack, or by stuff >>> that was automatically submitted by packit. It's one of the reasons >>> why we now have a policy that requires actual people to be responsible >>> for all builds submitted by bots. >>> >>> Even if we had a mechanism to trigger automatic rebuilds of dependent >>> packages (i.e. "I have detected that the sonames of the libraries in >>> this package have changed, let me also rebuild dependent packages for >>> this!") only works *if* (and that's a big *if*) the ABI change isn't >>> accompanied by breaking API changes, as well. What would you want to >>> happen then? I'm pretty sure software isn't smart enough yet to >>> determine in advance if any breaking API changes affect any dependent >>> packages. >> >> This is going to be true for the majority of Haskell and Rust package >> updates if Fedora ever decides to use dynamic linking for them. >> Same for lots of C++ template libraries. > > Do you have any indication that the Rust language and build system are > working on supporting this? > > Fabio Rust *already* has full dynamic linking support, and this is used on Android to save space and memory. What Rust does not have is a stable ABI. Therefore, when Rust code changes, all Rust code depending on it must be recompiled. The same is true for Haskell with GHC. To make this maintainable, the necessary recompiles must be automated, so that when a new version of e.g. hyper is pushed, all packages that use hyper are rebuilt automatically. Fedora *should* be doing this for C++ template libraries already, as C++ templates are not included in any static or shared libraries. They are only found in headers, and so changing them requires all code that uses them to be recompiled. Not doing so is technically a violation of the One Definition Rule, and in any case it means that bug fixes in the template code will not propagate without the code using the templates being recompiled. The same is true for C inline functions. For instance, PipeWire had some bug fixes in the SPA config file parser, but that is an inline function, so code will need to be recompiled to get the benefit of these changes. -- Sincerely, Demi Marie Obenour (she/her/hers) _______________________________________________ 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
