On Sat, Jul 23, 2022 at 2:01 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Sat, Jul 23, 2022 at 7:47 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > > > - the sets of dependent packages overlap between concurrently created side tags > > So what? If we're not tracking rebuilds in Git anymore, this is no > longer a serious problem. The build system knows every time a commit > is requested and increments the counter accordingly. So what? This is definitely a problem that would need to be solved somehow. Assume a package X that depends on both libfoo and libbar, and there's concurrent soname bumps for those two libraries. Then package X gets rebuilt in side-tag M for the libfoo soname bump, and rebuilt in side-tag N for the libbar soname bump, but it would need to get rebuilt against *both* in order to result in a working package. The only way to solve this would be to serialize builds for side tags instead of running them in parallel, or to run builds multiple times, until installability tests etc. succeed. > The fundamental difference between your thought and mine is that you > want it to be perfect. I want it to be good enough to eliminate the > *majority* of provenpackager grunt work and stop punishing people so > hard for bringing useful software library packages into the > distribution. > > Failure is okay. Human intervention is fine. Design a process that > handles 80% and make it gracefully fail for the remaining 20%. > > You seem to think it's unworkable, but I work in a Linux distribution > that operates this way and has for twenty years! I *know* it works. > It's not perfect, and there's certainly going to be some human > intervention and probably some configuration stuff to resolve things > machines can't figure out on their own (like build cycles and things > of that nature), but it is absolutely possible to do this and make the > lives of the majority of packagers easier. I'm not saying it's impossible, but I think in our current state, we wouldn't end up with "80% are fine and 20% would require manual intervention", but rather the other way round. And at that point, any automated mechanism starts to be rather useless - which is why I'd like to improve the underlying problems *first* and then implement automation that *actually works in the majority of cases* later. 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
