2019-02-15

Proposed Change to EPEL Policies: Minor Release Based Composes

I proposed this on the EPEL list earlier this week, but realized it needed more views so am putting a version on the blog. The canonical version is at https://fedoraproject.org/wiki/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@fedoraproject.org

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 following:

/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}

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

/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.  For example, on 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


Release Notes


Discussed on epel-devel@lists.fedoraproject.org list with updates taken into concern.

No comments: