Hello Fedora EPEL maintainers!
First I don't feel comfortable announcing this, I'm not happy about the
situation and so I don't want to be the lightning rod :-). But I believe
that we can come to acceptable Copr/Mock solution and this needs to be
discussed... so here we are.
By the end of the year 2021 we have to fix our default EPEL 8 Mock
configuration (mock-core-configs.rpm, /etc/mock/epel-8-*.cfg) as CentOS 8
goes EOL by then.
The same thing needs to happen in Fedora Copr, with the epel-8-* chroots
(side note, in Fedora Copr we use the mock-core-configs package for builds
without any deployment specific modifications).
I am proposing (as PR against mock upstream ATM [1]) to switch the default
epel-* configuration from CentOS+EPEL to RHEL+EPEL as soon as possible
(see the pull request [1]).
This would bring some consequences, namely newly with epel-8* chroots,
- builds will require a valid Red Hat subscription (the no-cost variant is
OK as well, though [2])
- we will miss some build-time packages that Red Hat is not shipping, at
least at the beginning till they are added (to RHEL CRB, or other
currently unknown place).
- cross-arch compilation can not be used, Red Hat subscriptions don't
allow that (using QEMU and rpm --forcearch), [3]
The positive thing is that the default configuration will be much closer
to the official EPEL builds (because Fedora Koji EPEL builds are actually done
also against RHEL).
For the Fedora Copr builders, we already have the necessary Red Hat
subscriptions in hand (will be deployed by the end of the year). So we will
only loose the opportunity to build on emulated epel-8-armhfp permanently, and
epel-8-s390x temporarily (as we already work on the native s390x support).
Any thoughts? Feedback is needed here.
[1] https://github.com/rpm-software-management/mock/pull/802
[2] https://rpm-software-management.github.io/mock/Feature-rhelchroots
[3] https://bugzilla.redhat.com/show_bug.cgi?id=1912847
Pavel
Hello maintainers,
the Copr project is in the process of implementing the PULP storage
backend (RPM repo management technology):
https://github.com/fedora-copr/copr/issues/2533
We expect that this change will be slow and incremental (we will not move
all projects to PULP at once) and that it is going to be almost an 1:1
replacement. See that tracker link above if you want more info.
There's one technical detail/change that seems to be clear right now and
is worth announcing in advance - the way we handle the duplicate NEVRAs in
the same repos is going to change (a bit). Before or after the switch,
Copr simply allows you to build packages with the same/duplicate NEVRAs
into the same repository. There's no reason to fail the build process.
The current (old) behavior though is that Copr keeps all the duplicates in
the RPM repository - and DNF is confused (when asked to install one of
such duplicate NEVRAs, it picks one of them by random, or by package ID,
or it is DNF version specific behavior, or - I don't really now). Project
administrators can then come anytime later and decide which particular
build ID they want to keep, and delete the rest of the duplicate builds.
So the confusion can be resolved pretty easily.
The new (with PULP) behavior will be that the newer duplicates
will override the previous - this is on one hand good, because DNF
is not confused - always sees the latest "duplicate" NEVRA to install.
But on the other hand this also means that, when the latest NEVRA build is
removed, Copr will drop the NEVRA from the metadata (it will not present
the older builds).
This is just a headsup for you, feel free to comment here or ideally in
the corresponding Copr issue
https://github.com/fedora-copr/copr/issues/3262
Thank you, and happy building!
P.S. When you build only for the purpose of building (to check there's no
FTBFS) you are not affected. If you bump Release regularly (you should),
you won't be affected.
Pavel