Re: Feedback wanted for a proposed improvement to RPM's ELF dependency generator

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 19, 2023 at 01:33:33PM -0800, Gordon Messmer wrote:
> On 2023-02-19 12:30, Stephen Smoogen wrote:
> > 
> >     > - You mention "over the course of two releases" but don't
> >     mention what
> >     >    is done in each one?
> > 
> >     I don't know the specifics of how package builds are ordered in a
> >     mass
> >     rebuild, so I tend to think the safest rollout is a slow one:
> >     enable the
> > 
> > 
> > I think they are usually done 'alphabetically' with various subgroups
> > done in 'order by the maintainer' beforehand (or afterwards if the mass
> > rebuild broke it) as additional side-tags.

Yes, mass rebuild is done in a-z order in a rebuild side tag. None of
the builds update the buildroot, they just inherit the normal rawhide
buildroot.

> If there's no dependency ordering in the mass rebuild, then I think the
> shortest possible timeline for enabling both macros would be to enable
> _elf_provide_fallback_versions globally, wait for the next mass rebuild, and
> then globally enable the _elf_require_fallback_versions macro.  At that
> point, dependencies should have been made consistent by the mass rebuild,
> and improved dependency information should be generated as it's needed (as
> packages are built after the mass rebuild).
> 
> However, FTBFS very probably means that a short timeline like that would be
> difficult, as once _elf_require_fallback_versions was enabled globally any
> packages that depend on something that didn't rebuild would need to be opted
> out of the system temporarily by disabling _elf_require_fallback_versions in
> their spec file.  So, it might be preferable to roll out that half of the
> system later.

Right, mass rebuild doesn't mean everything is rebuilt, but most things
are. 

kevin

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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, report it: https://pagure.io/fedora-infrastructure/new_issue

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux