On Tue, 8 Mar 2022 15:46:29 +0100 Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > On Tue, Mar 8, 2022 at 2:05 PM Chris Adams <linux@xxxxxxxxxxx> wrote: > > > > Once upon a time, Fabio Valentini <decathorpe@xxxxxxxxx> said: > > > One of the most problematic things are transitive BuildRequires: > > > Even if you know you need to keep libfoo.i686 and libbar.i686, how do > > > you determine the transitive dependencies that are needed to keep > > > those packages around? > > > And by that, I don't only mean Requires, but also transitive > > > BuildRequires, i.e. if libfoo BuildRequires foolangc, which > > > BuildRequires some other stuff, etc, all of which still needs to be > > > there, or at some point, libfoo.i686 will either fail to build or fail > > > to install. > > > > All the necessary info is in the source RPM BuildRequires. Yes, you'll > > need a script to build the list recursively, but... that's not that > > hard. > > It's not that easy either. > > For example, if you're not careful to avoid dependency loops, you'll > create a program that will never terminate. > You'll need to recursively query Requires from those BuildRequired packages, > but you also need to map those their respective source packages, and > continue with querying BuildRequires recursively. > > I've tried to write a script that does that, but it doesn't provide > correct results yet. > If I manage to get it working, I can share it. please see my previous post, I have/had a solution for the transitive build requirements Dan > > > > I have thought about this issue for months before submitting this > > > Change proposal, and it's the best I think we can do without breaking > > > tons of stuff or requiring massive amounts of work from the Change > > > owner (me). At this point, I do think that a safe and officially > > > encouraged opt-out mechanism for individual package maintainers is the > > > only way we can do this *safely* at all. > > > > There are almost 23,000 source RPMs in rawhide. You are proposing a > > change that puts virtually all the effort on the maintainers of the > > majority of those packages, rather than write a script yourself (which > > should not be "massive amounts of work"). > > > > It's easy to propose something when somebody else has to do the work; > > please instead put some work in yourself (or don't propose the change). > > I would appreciate it if you actually read the proposal instead of > making personal attacks like this: The proposal does not create a > mandate for package maintainers for dropping i686 from packages at > all. > > The goal is to make it easier for maintainers if they are already > thinking about dropping i686 from their package. I will also provide a > list of potential candidate packages, but it will still be up to the > maintainers whether they incorporate or ignore this change. > > So I don't understand how this "puts virtually all the effort on the > maintainers of the majority of those packages", if completely ignoring > the Change and/or inaction are both perfectly valid choices. > > 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 _______________________________________________ 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
