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.