releng

#10735 Link to current $releasever in https://dl.fedoraproject.org/pub/archive/epel/?
Closed: Fixed by smooge. Opened by brianjmurrell.

Closed: Fixed
Reopen Issue
  • Describe the issue
    https://dl.fedoraproject.org/pub/archive/epel/ has an 8 subdir. It's misleading that this subdir is not actually the current EPEL 8. I could argue that while of course all of the 8.[0-9] subdirs should obviously be there, 8 should not.
    However, more strongly I would argue that https://dl.fedoraproject.org/pub/archive/epel/8 be a symlink to ../../epel/8 so that it's the current $releasever. This would make https://dl.fedoraproject.org/pub/archive/epel/ a functional URL in .repo files that would work as expected with $releasever. I.e.: 
baseurl=https://dl.fedoraproject.org/pub/archive/epel/$releasever

for any/every valid value of $releasever including it's current default of 8.

  • When do you need this? (YYYY/MM/DD)
    ASAP would be nice. It's a simple change.

  • When is this no longer needed or useful? (YYYY/MM/DD)
    Needed forever.

  • If we cannot complete your request, what is the impact?
    Not being able to construct useful baseurls for EPEL to be able to test with previous releases of EL8, for backwards compatibility for example.

Metadata Update from @smooge:
- Issue assigned to smooge

You are correct and the 8 should not have been there. We have removed the link.

Metadata Update from @smooge:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

Issue status updated to: Open (was: Closed)

Metadata Update from @mohanboddu:
- Issue tagged with: low-gain, low-trouble, ops

You are correct and the 8 should not have been there. We have removed the link.

It's really a pity that this is the resolution you chose rather than the other option I suggested. Now there has to be two completely different places (i.e. baseurls) to get an epel release from depending on whether you want current or a historical one.

Understood, but that was not the expressed purpose of archives of EPEL. EPEL is a rolling repository and this snapshot archives are only done around the time a new X.Y release of RHEL comes out to allow for people who need to stick to something for a month or so. It is not meant for 'general' usage and would probably cause security and other problems is used that way. [It would also cause network bandwidth problems for Fedora because very few sites mirror archives so you are hitting the main 3 download servers that every top level mirror needs to get other things.]

The link you found was erroneous from an initial rsync and should have been removed long ago.

I would bring this up with the EPEL steering committee on how to better do this in the future.

Metadata Update from @smooge:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

people who need to stick to something for a month or so

Or longer? What about people who are on RHEL Z-stream releases? Surely this archive facilitates those older (supported) systems, yes?

cause security and other problems is used that way

Perhaps, for production installations. But these archives together with a reference to the current version in the same tree location, and being able to select which one is used through $releasever is a cornerstone of being able to do backward compatibility testing by ISVs to ensure their software will be able to continue to support older EL releases -- supported (i.e. z-stream) or otherwise (i.e. those stuck for a month or so).

bandwidth problems

Anyone using these, i.e. for backwards compatibility testing, really ought to be locally caching so that they are only hitting the upstream for an initial copy of a package and using their local cache for repeated fetches.
Metadata

low-gain low-trouble ops

None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.