On Thu, Jun 26, 2025 at 12:16:21PM +0200, Fabio Valentini wrote: > On Thu, Jun 26, 2025 at 12:09 PM Daniel P. Berrangé <berra...@redhat.com> > wrote: > > > > On Thu, Jun 26, 2025 at 11:50:10AM +0200, Fabio Valentini wrote: > > > On Thu, Jun 26, 2025 at 11:24 AM Vít Ondruch <vondr...@redhat.com> wrote: > > > > > > > > Reading through the feedback, wouldn't it be better to take a second > > > > look on the previous change: > > > > > > > > > > > > Dne 24. 06. 25 v 12:02 Aoife Moloney via devel-announce napsal(a): > > > > > Since Fedora 37, leaf packages (i.e. packages that are not depended on > > > > > by other packages) can simply > > > > > [https://fedoraproject.org/wiki/Changes/EncourageI686LeafRemoval stop > > > > > building for i686] without any reason, which has allowed package > > > > > maintainers to focus their work on architectures where packages are > > > > > actually shipped to users. > > > > > > > > > > > > > While it encourages removal of i686, I think that nobody was ever really > > > > serious about this. > > > > > > Yes, because it's not trivial ... > > > > > > I wrote https://pagure.io/leafdrop to help packagers with this, but > > > (see below) its guidance is imperfect. > > > > Also the definition of "leaf" that is has to use is overly restrictive > > compared to the real world usage. With multi-lib only a small subset > > of i686 packages make their way into the compose, but the build system > > still requires we build everything, no matter the fact most won't ever > > see the light of day outside the build system :-( > > > > So the idea of only dropping packages which are leaves in koji, is way > > too narrow of a goal to enable sufficient progress to be made to get > > down to only the small set of RPMs needed in real world deployment. > > Yes, by design, it *should* give you no "false positives" (i.e. tell > you that you can drop something that you actually can't), but it will > give you "false negatives" (i.e. tell you that you can't drop > something that you actually could drop) - which, given limitations of > the data we have, is the safe way to handle this, in my opinion.
Yes, but that is also precisely why the "encourage leaf drop" change makes very little dent in the maint burden we face. In the non-leaf case, for each binary RPM identified, someone has to look at the dep and decide whether the functionality can be selectively disabled on i686 via an RPM spec condition, or the package fully disabled on i686. There are 32 source packages (40 binary packages) as 1st level needing investigation when QEMU drops i686 support likely later this year, which likely implies following many recursive deps too. Some 1st level deps are pretty core to the distro like koji, openqa, lorax but at the same time few of these seem relevant to multi-lib usage. With regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :| -- _______________________________________________ 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, report it: https://pagure.io/fedora-infrastructure/new_issue
