[CentOS-devel] Handling packages retired in epel but not yet available in CentOS?

Fri May 15 13:06:16 UTC 2020
Nico Kadel-Garcia <nkadel at gmail.com>

On Fri, May 15, 2020 at 8:02 AM Stephen John Smoogen <smooge at gmail.com> wrote:
> On Thu, 14 May 2020 at 20:00, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>> On Thu, May 14, 2020 at 3:32 PM Michel Alexandre Salim
>> <michel at michel-slm.name> wrote:
>> >
>> > Hi,
>> >
>> > We're working on validating CentOS 8 for some desktop use cases at work,
>> > and noticed that after working fine on a machine that's installed
>> > several months ago, it's now failing on a freshly-installed machine.
>> Do not get me *started* on the ansible version fun and games, or the
>> confusing state of the python3 for various EPEL, RHEL and CentOS
>> migrations. The situation is exacerbated when RHEL elects to use a
>> kind-of-sort-of distinct naming scheme for software previously
>> published via EPEL.
>> It's an ongoing problem. EPEL's decision to show only the most recent
>> versions of RPMs, and to trim old RPMs out, is a destabilizing problem
>> and why I make hrdlinked snapshots of EPEL using "rsnapshot" for
>> internal access to old packages.
> To be clear here.. the 'decision' is that EPEL is built using the same build system that Fedora uses. The Fedora build system does not keep older versions of packages in its composes for a space and so EPEL can not keep older versions of packages either. We tried several 'hacks' to do this and they broke the Fedora side or didn't do what we wanted on the EPEL side either.

That is not clear at all. Build systems normally build new versions of
software and deploy them to some target space. The decision to delete
older packages is a very distinct one. Review of that workspace and
expiration of old packages pretty much *must* be a distinct one.
Deletion of obsolete packages in anticipation of their activation in
an entirely distinct repository  is a very distinct decision.

EPEL does duel publication of upstream RHEL published packages with
ansible. I really don't see any reason why the older EPEL packages
can't be left in place until well after they are published in CentOS,
not merely RHEL, as a courtesy to the far larger CentOS user
community. And yes, I've had to build my own internal package of an
older EPEL release  until CentOS published a release myself a few
times. It's going on right now with python 3 packages as the migration
to "python3" based package names continues.

These can be automated. But publication to a common workspace is not
the same as preservation of an internal workspace. I could believe
that synchronization among them are automated.

> At this point it is either someone finding the time to deep dive into pungi and other tools to make it work for this 2 different case mode or moving EPEL to a different build system. Both are giant projects which no one has had the time to do.

Or, simply stop deleting the older RPMs from the mirrors.There is a
cost, mirroring would take more scanning and more bandwidth to keep
the mirrors. Metadata would also accumulate and cause some additional
burden.  But let's not confuse a model with one repositories building
workspace with the same project's publication workspace. I've actually
been through this one a few times in public and private software
repositories: it can take a bit of thought.