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

Fri May 15 13:57:23 UTC 2020
Stephen John Smoogen <smooge at gmail.com>

On Fri, 15 May 2020 at 09:06, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> 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.
>
>
I believe Dennis Gilmore and others have tried to explain this multiple
times in the past, but it seems that it just doesn't get through. Here is
my take on it.. which is not as nice as theirs and probably flawed because
I am tired.

The Fedora build system means everything from pkgs, pdc, bodhi, koji,
pungi, and several other tools. The way that this system is built is to
build a complete operating system with the 'compose' being just like what
is in rawhide or a release. Everything is tagged to be in the compose, a
fresh tree is generated, createrepo and other items are built on that tree,
and that tree then replaces the old one on the download servers. Just like
F32 directories and rawhide do not have older copies of packages.. neither
does EPEL.  So to the system there are no old rpms to keep around.. [and
trying to keep them seems to end up with a good many mirrors carrying new
packages but old repodata (or vice versa.. new repodata but no new rpms) so
can't be used by yum/dnf]

Of course there could be other solutions that would fix this problem.. but
each one takes time and energy that no one seems to have the time to
volunteer to get done. If you have the time to do so, I am sure people will
welcome it.



-- 
Stephen J Smoogen.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.centos.org/pipermail/centos-devel/attachments/20200515/0c965791/attachment-0007.html>