Small technical concern:
i686 packages depending on each other as follows:
A ---> B ---> C ---> D ---> E ---> F ---> G
When a maintainer of package "D" decides to stop building the package
"D" for i686 ("ExcludeArch: %{ix86}"), how do we ensure the packages
"E", "F", "G" will also adopt the "ExcludeArch: %{ix86}" instead of
FTBFS (or FTI) on i686 arch ?
The original change proposal is about _leaf_ packages, which I
understand as only package "G" in my example.
And the maintainer of "D" has to wait on the maintainer of "E" has to
wait on the maintainer of "F" has to wait on the maintainer of "G" to
stop building it for i686.
As voices appeared proposing to get rid of _all_ i686 but necessary
instead (which has +1 from me), I'm unsure whether the goal of the
original proposal changed.
I'm just asking to make sure whether that's somehow covered.
--
Michal Schorm
Software Engineer
Core Services - Databases Team
Red Hat
--
On Tue, Mar 8, 2022 at 4:07 PM Dan Horák <d...@danny.cz> wrote:
>
> 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
_______________________________________________
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
