EPEL/Changes/Minor release based composes

Summary

The change moves EPEL composes to biannual based composes and adds an updates tree for consumers. Package trees will have a naming structure similar to Fedora release names, and will be regularly archived off to /pub/archives after the next minor release.

Package lifetimes will be similarly affected with the expected minimum 'support' lifetime of any package to be that of a minor release.

Owner

• Name: Stephen Smoogen
• Email: smooge@gmail.com

Detailed Description

Extra Packages for Enterprise Linux is a sub-project of Fedora which recompiles various Fedora packages against various Red Hat Enterprise Linux releases. Currently these packages are composed by the Fedora release engineering tools similar to Fedora Rawhide where only the latest packages tagged for a particular EPEL release (example epel-7) appear. When a package is updated or retired, the older version falls out of the EPEL repositories and users can not downgrade to older versions.

The tree structure would look like the follows

 /pub/epel/releases/Major.Minor.YYYYMM/{Stuff,Modular?}/{x86_64,ppc64le,aarch64,s390x,source}/{Packages,repodata}
 /pub/epel/updates/Major.Minor.YYYYMM/{Stuff,Modular?}/{x86_64,ppc64le,aarch64,s390x,source}/{Packages,repodata}

[where Modular shows up for releases with Modular content]

with 2 sets of symlinks pointing to the latest supported tree:

 Examples:
 /pub/epel/releases/7.06.201903/Stuff/x86_64/Packages/
 /pub/epel/releases/8.00.2019MM/Modular/source/Packages/

 /pub/epel/updates/7.06.201903/Stuff/aarch64/Packages/
 /pub/epel/updates/8.00.2019MM/Modular/s390x/Packages/

 /pub/epel/releases/7  -> /pub/epel/updates/7.06.201903
 /pub/epel/updates/7  -> /pub/epel/updates/7.06.201903

The proposed change will move EPEL minor releases to match with Red Hat minor releases. As of 2019-02-10, Red Hat has Red Hat Enterprise Linux 7.6 in Full Support/Maintenance mode and has released a beta for RHEL-8. With the change, EPEL would compose a special set of trees for March 2019 and then all updates for those packages would go into the appropriate /updates/ sub-tree.

When the next minor release is released from Red Hat, a new compose tag will be made in koji. Packages which are not retired will then be pulled into the tag, and proven packagers can stage any mass rebuilds needed for rebases. When testing shows that this tree is ready, the symlinks will then be moved to the new tree, and the old tree will be prepared to move over to /pub/archives

Packages which are added to EPEL after a major.minor compose will only show up in the /updates/ tree until the next major.minor compose. This is the same as packages in Fedora.

Due to the fact that RHEL-6 has only a year and a half of Maintenance mode, we are not looking at making changes unless it turns out that we have to.

Benefit to Fedora

• Users are able to downgrade to an earlier version if an update has issues for them
• Packages will less likely break for Scientific Linux and CentOS users during minor updates.
• Packages will be regularly archived off to /pub/archives/epel/ and consumers will less likely pull large number of old packages out of koji looking for older software.

Scope

• Proposal owners:
  • Add koji tags for date releases
  • Write scripts for releng to make new releases

• Other developers:
• Policies and guidelines:
• Trademark approval: N/A

Known Change Impacts

Users who have hard-coded repositories or mirror specific directory changes may have a 'broken' experience due to symlink changes.

Archives will grow every 6 months as packages are put there regularly.

How To Test

We will stage this set of changes in /pub/alt/epel before rolling out to the main EPEL. Users wishing to test this can set up systems that will point to this tree using a temporary .repo file to be provided for testing.

User Experience

User's should be able to do the following:

* yum install package-name
* yum upgrade package-name
* yum downgrade package-name

Contingency Plan

• Contingency mechanism: (What to do? Who will do it?) If testing shows this proposal to fail we will not release.
• Contingency deadline: 2019-04-01
• Blocks release? No (we don't do releases yet).
• Blocks product? Yes