Stephen John Smoogen wrote:
> So part of the reason for this is that the old method of trying to
> make this happen is broken.
>
> In EPEL-6 and EPEL-7 we would have a person who needed a package dep
> to rebuild the package in EPEL but with a slightly lower NVR to make
> it so we did not replace on the x86_64 platform whatever missing
> package there was. However what happens constantly is that those
> packages end up never getting updated so any updates in RHEL can cause
> CVE warnings or other problems. Or some packager who doesn't know this
> package can't be upgraded to the latest, does so.. and we have now
> broken customers on x86_64 with no way to 'fix them'. Since the ratio
> of x86_64 to the next major architecture is 100,000:1 that is a lot of
> boxes broken for some smaller set.
>
> So for EPEL-8 we are not allowing for the 'limited arch' packages. At
> this point if a package is not shipped across architectures, please
> use Exclusive Arch towards the ones it is shipped on'.
Wouldn't the proper solution be to rebuild those packages by an automated
process (using just a manually maintained list of affected packages, and
then having a builder automatically watch for updates in RHEL and rebuilding
them for the additional architectures) and put them into some extra
epel-limitedarch repository?
In other words, the proposal is to:
* not import those packages into EPEL dist-git at all, but rebuild them
directly from CentOS dist-git or wherever RHEL pushes the sources to
(any unwanted ExcludeArch/ExclusiveArch can be eradicated with sed),
* maintain only a list of source package names in EPEL,
* publish only the binary packages and only for the architectures not
shipped in RHEL, possibly in a repository separate from EPEL proper (but
which EPEL proper would require),
* do all of the above with an automated script,
* drag in the above repository in EPEL Koji in addition to RHEL.
I think this would avoid the error-prone manual process that was used in
EPEL 6 and 7 while still doing the needed package rebuilds.
This process could even be adapted to also handle missing subpackages
(across all architectures), if the Code Ready Builder remains as incomplete
as it is now. The script would just have to be taught to publish only the
specific subpackages and throw away everything already published in RHEL.
Kevin Kofler
_______________________________________________
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
