Re: F37 Change: Encourage Dropping Unused / Leaf Packages on i686 (Self-Contained Change proposal)

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

 



Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> said:
> What about the following instead:
> - We start with a filter list that includes glibc, wine, and other
>   packages which we know should be excluded.
> 
> - The script is run automatically and identifies a list of leaf packages.
> 
> - For packages which are leafs not on the filter list, a pull request
>   is opened to add ExcludeArch: %{ix86}.
> 
> - If the pull request is merged, fine. If it is closed w/o merge, also
>   fine. If the maintainer doesn't react in a week, the request is merged
>   automically and the package built.
> 
>   Either way, the package is added to a filter list to not bother the
>   maintainers again.
> 
> I think it should be possible to automatize steps 2–4. This way
> we'll not need to wait for maintainers to add ExcludeArch manually.
> Elsewhere in the thread people suggested that this would take forever
> if manual steps are required, and I fear that this is a valid assesment.

Rather than churn 20,000+ packages (plus add a new requirement for every
new package to include an ExcludeArch), why not address this at the
build system?

Writing a script to generate a list of the buildroot plus multilib
packages, then find all the necessary source packages for those and
their build dependencies, should not be that hard.  I don't know how
difficult it would be to then hook that in as a filter to the i686 build
system, hopefully not too difficult?

I don't know how the current list of provided multilib packages is
created though.  I'd probably start with the above script querying all
i686.rpm packages in the x86_64 repo (and working through their source
packages, and those packages' build deps), and if the i686.rpm list is
slimmed down, the above script would trim the deps automatically.

Then rather than churn almost every package in the distribution, current
and future, fix it in one place.  That place can then be updated as
needed.

-- 
Chris Adams <linux@xxxxxxxxxxx>
_______________________________________________
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




[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