RFC: Package maintenance and update policy for EPEL

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

find below my take for a "Package maintenance and update policy for
EPEL". You an find it in the wiki at:
http://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies/PackageMaintenanceAndUpdates

It has been discussed on the epel-devel-list already last week (received
some comments, but only a few), but I thought it might be best to
actually bring it up one this list once here, too.

Did I miss anything? Do people like the general direction?

CU
thl

P.S.: If you spot typos (there are probably still some...) please fix
them in the wiki directly -- that's why the document is there ;-)

----

= Package maintenance and update policy =

EPEL wants to provide a common "look and feel" to the users of our
repository. Thus the EPEL SIG wrote this policy that describes the
regulations for package maintenance and updates in EPEL, that are a bit
more strictly regulated then they are in Fedora now.

[[TableOfContents]]

== Digest ==
## INCLUDEPOLICYFRONTSTART

The goal is to have packages in EPEL that enhances the Enterprise Linux
distributions the packages were build against without disturbing or
replacing packages from that distribution. The packages in the
repository should, if possible, be maintained in similar ways to the
Enterprise Packages they were built against. In other words: have a
mostly stable set of packages that normally to not change at all and
only changes if there are good reasons for it -- so no "hey, there is a
new version, it builds, let's ship it" mentality.

## INCLUDEPOLICYFRONTEND

[[Anchor(afterinclude)]]

== Policy ==

EPEL packages should only enhance and never disturb the Enterprise Linux
distributions they were build for. Thus packages from EPEL should never
replace packages from the target base distribution; kernel-modules
further are not allowed, as they can disturb the base kernel easily.

The packages in the repository should, if possible, be maintained in
similar ways to the Enterprise Packages they were built against. In
other words: have a mostly stable set of packages that normally does not
change at all and only changes if there are good reasons for changes.
This is the spirit of a stable enterprise environment.

The changes that cant be avoided get routed into different release
trees. Only updates that fix important bugs (say: data-corruption,
security problems, really annoying bugs) go to a testing branch for a
short time period and then build a second time for the stable branch;
those people that sign and push the EPEL packages to the public repo
will skim over the list of updated packages for the stable repo to make
sure that sure the goal "only important updates for the stable branch"
is fulfilled.

Other updates get queued up in a testing repository over time. That
repository becomes the new stable branch in parallel with the quarterly
update that get released by the Linux Distributor that creates the
Enterprise Linux the packages gets build against. There will be a short
freeze time period before the quarterly update happens to make sure the
repo and its packages are in a good shape -- packages in this phase
still can be removed if thats is needed. But even this updates should be
limited to fixes only as far as possible and should be tested in Fedora
beforehand if possible. Updated Packages that change the ABI or require
config file adjustments must be avoided if somehow possible. Compat-
Packages that provide the old ABI need to be provided in the repo if
there is no way around a package update that changes the ABI.

== Guidelines and Backgrounds for this policy ==

=== Some examples of what package updates that are fine or not ===

Examples hopefully help to outline how to actually apply above policy in
practise.

==== Minor version updates ====

Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1;
upstream developers now ship 1.0.2

 * build for the stable branch only if it fixes serious bugs
 * build for the testing branch (which will be 5.1 later) is acceptable
if the upstream release is mostly a bugfix release without new features
and the package got run-time testing

==== A little bit bigger minor version updates ====

Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1;
upstream developers now ship 1.2.0; the ABI is compatible to 1.0.1 and
the existing config files continue to work

 * build for the stable branch only if it fixes a really serious bug
 * build for the testing branch (which will be 5.1 later) is acceptable
if it fixes serious bugs

==== A yet again little bit bigger minor version updates ====

Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1;
upstream developers now ship 1.4.0; the ABI is compatible to 1.0.1, but
the config files need manual adjustments

 * build for the stable branch is normally not acceptable; a backport
should be strongly considered if there are any serious bugs that must be
fixed
 * build for the testing branch (which will be 5.1 later) is also
disliked; but it is acceptable if there is no other easy way out to
solve serious bugs; but the update and the config file adjustments need
to be announced to the users properly -- say in form of release notes
that get published together with the quarterly announcement.

==== A major version update ====

Let's assume package foo is shipped in EPEL 5.0 as version 1.0.1;
upstream developers now ship 2.0.0; the ABI changes or the config files
need manual adjustments

 * this update should be avoided if possible at all. If there really is
no other way out to fix a serious bug then it rare cases it might be
acceptable to build the new version for the testing branch and mention
the update and the needed adjustments in the release notes for the next
update. An additional compat- packages with the old libs is necessary if
the ABI changed.

==== Add more examples as they show up ====

If to many show up put them into a separate document.

=== Still unsure if a package is fine for EPEL? ===

Just ask on [http://www.redhat.com/archives/epel-devel-list/ EPEL
developers mailing list] or #epel on freenode.org for opinions from EPEL
SIG members.

=== Why not a rolling release with up2date packages like Extras? ===

Why should we? That would be what Fedora (Extras) did and worked and
works well for it -- but that's mainly because Fedora (Core) has lots of
updates and a nearly rolling-release scheme/quick release cycle, too.
But the Enterprise Linux we build against is much more careful with
updates and has longer life-cycle; thus we should do the same for EPEL,
as most users will properly prefer it that way, as they chose a stable
distro for some reasons -- if they want the latest packages they might
have chosen Fedora.

Sure, there are lots of areas where having a mix of a stable base and a
set of quite new packages on top of it is wanted. *Maybe* the EPEL
project will provide a solution (in parallel to the carefully updated
repository!) for those cases in the long term, but not for the start.
BTW, there are already repositories out there that provide something in
this direction, so users might be served by them already.

Further: A rolling release scheme like Fedora (Extras) did/does is not
possible for many EPEL packages for another reason, new packages often
require new versions of certain core libraries.  This will cause
problems in EPEL because we won't be able to provide updated libs as it
would replace libraries in the core OS.

Example: This document was written round about when RHEL5 got released;
many packages that get build for RHEL5 can't be build for RHEL4 at this
point of time already, as the RHEL4-gtk2-Package is two years old and is
to old for many current applications, as they depend on a newer gtk2. So
if even if we would try to have a rolling scheme with with quite new
package we'd fail, as we can't build a bunch of package due to this
dependencies on libs; in the end we would have a repo with some quite
new packages while others are still quite old. That mix wouldn't make
either of the "latest versions" or "careful updates only" sides happy;
so we try to target the "careful updates only" sides.  Remember, EPEL's
support cycle is much longer then Fedora's.

=== How will the repo actually look like ===

Similar to what [ http://ftp-stud.fht-esslingen.de/pub/Mirrors/centos/
layout] CentOS uses. Rough example:

{{{
* epel/                         # topdir
 * 4/                           # topdir for EPEL4
  * 4 -> 4.5                    # symbolic link to latest version
  * 4.1/                        # this tree of course will never exists,
as this is history, and is here just to show the example
  ....                          # 4.2, 4.3, 4.4; those won't ever
exists, too
  * 4.5/                        # 4.5, latest version, build target:
fedora-epel-4-stable
  * 4.6                         # not yet
  * ....                        # time will come
  * testing/                    # testing repo, that together with the
old packages that didn't get update becomes 4.6 when RHEL 4.6
                                # releases; build target: fedora-epel-5;
gets frozen for a week or two before the quarterly update is
                                # issued; new packages land here for a
while, too

 * 5/                           # topdir for EPEL4
  * 5 -> 5.0                    # symbolic link to latest version
  * 5.0/                        # 5.0, latest version, build target:
fedora-epel-5-stable
  * 5.1                         # not yet
  * ....                        # time will come
  * testing/                    # testing repo, that together with the
old packages that didn't get update becomes 4.6 when RHEL 4.6
                                # releases; build target: fedora-epel-5;
gets frozen for a week or two before the quarterly update is
                                # issued; new packages land here for a
while, too
}}}

This layout may looks complicated, but has one major benefit: Users can
stick to a EPEL repo for a not up2date EL release while a newer EL
quarterly update is already out (some users do that on purpose, others
have no chance as for example the CentOS update gets normally released
up to four weeks after RHEL released a quarterly update). The above
layout can makes it possible to prevent that users run into dependency
issues that might arise otherwise if packages in the new EPEL release
depend on new packages in the new EL release. The EPEL quarterly update
further isn't forced on users before they switch to the quarterly update.

Each repo always has all the packages in it; hardlinks will be used to
keep the space requirements on the server-side limited, as most packages
won't change.

=== What about EPEL4 ===

We start EPEL two years after RHEL4 started getting shipped. Pushing out
packages today that were up2date two years ago might look a bit odd and
will be hard to realize -- what version to choose exactly? So we simply
take a slightly different route for EPEL4 and suggest our maintainers to
consider using the stuff from http://centos.karan.org/  (which are based
on Fedora Extras 3) as base for packages in EPEL4 -- that stuff is known
to work and tested, so is a good base for the EPEL4 branch. Sure, the
outcome would have looked a bit different than where we might have
landed if we would have started EPEL two years ago, but well, we start
now. ;-)

--
Fedora-maintainers mailing list
Fedora-maintainers@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers

--
Fedora-maintainers-readonly mailing list
Fedora-maintainers-readonly@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly

[Index of Archives]     [Fedora Users]     [Fedora Development]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]

  Powered by Linux