On Fri, 15 May 2020 at 09:06, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:
On Fri, May 15, 2020 at 8:02 AM Stephen John Smoogen <smooge@xxxxxxxxx> wrote:
>
>
>
> On Thu, 14 May 2020 at 20:00, Nico Kadel-Garcia <nkadel@xxxxxxxxx> wrote:
>>
>> On Thu, May 14, 2020 at 3:32 PM Michel Alexandre Salim
>> <michel@xxxxxxxxxxxxxxx> 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.
_______________________________________________ epel-devel mailing list -- epel-devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to epel-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/epel-devel@xxxxxxxxxxxxxxxxxxxxxxx
