On Tue, 8 Mar 2022 15:46:29 +0100
Fabio Valentini <decatho...@gmail.com> wrote:
> On Tue, Mar 8, 2022 at 2:05 PM Chris Adams <li...@cmadams.net> wrote:
> >
> > Once upon a time, Fabio Valentini <decatho...@gmail.com> 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@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 on the list, report it:
> https://pagure.io/fedora-infrastructure
_______________________________________________
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 on the list, report it:
https://pagure.io/fedora-infrastructure
