| 1 |
klieber |
1.2 |
GLEP: 19
|
| 2 |
|
|
Title: Gentoo Stable Portage Tree
|
| 3 |
g2boojum |
1.6 |
Version: $Revision: 1.5 $
|
| 4 |
|
|
Last-Modified: $Date: 2004/02/02 18:16:31 $
|
| 5 |
klieber |
1.1 |
Author: Kurt Lieber <klieber@gentoo.org>
|
| 6 |
|
|
Status: Draft
|
| 7 |
|
|
Type: Standards Track
|
| 8 |
|
|
Content-Type: text/x-rst
|
| 9 |
|
|
Created: 26-Jan-2004
|
| 10 |
g2boojum |
1.6 |
Post-History: 29-Jan-2004 2-Nov-2004
|
| 11 |
klieber |
1.1 |
|
| 12 |
|
|
|
| 13 |
|
|
Abstract
|
| 14 |
|
|
========
|
| 15 |
|
|
|
| 16 |
|
|
This GLEP is intended to propose a series of changes to the Portage tree that
|
| 17 |
|
|
are necessary to facilitate the use of Gentoo in areas where stability and
|
| 18 |
|
|
predictability are of paramount importance, including servers in enterprise
|
| 19 |
|
|
environments, mission critical workstations and other such installations.
|
| 20 |
|
|
|
| 21 |
|
|
The proposed solution involves creating a separate tree in Portage that is
|
| 22 |
|
|
updated far less often than the regular tree. Outside of periodic updates,
|
| 23 |
|
|
this tree would only be updated with critical bugfixes and security patches.
|
| 24 |
|
|
|
| 25 |
g2boojum |
1.6 |
Status
|
| 26 |
|
|
======
|
| 27 |
|
|
|
| 28 |
|
|
Currently recruiting people who would be willing to help with this GLEP.
|
| 29 |
|
|
|
| 30 |
klieber |
1.1 |
Motivation
|
| 31 |
|
|
==========
|
| 32 |
|
|
|
| 33 |
klieber |
1.5 |
Enterprise users typically value stability and a predictable upgrade path
|
| 34 |
klieber |
1.1 |
over having the latest packages or features available to them. Historically,
|
| 35 |
|
|
Gentoo Linux has been unable to provide such an environment due to the dynamic
|
| 36 |
|
|
nature of the Portage tree.
|
| 37 |
|
|
|
| 38 |
|
|
Specification
|
| 39 |
|
|
=============
|
| 40 |
|
|
|
| 41 |
|
|
The Gentoo Infrastructure team will need to provide an additional Portage tree
|
| 42 |
|
|
on our rsync mirroring system. This new tree will house the ebuilds
|
| 43 |
|
|
associated with the stable tree. It also impacts all Gentoo developers
|
| 44 |
|
|
responsible for creating and updating ebuilds as they will be expected to
|
| 45 |
|
|
integrate the tagging of ebuilds for the stable tree into their normal
|
| 46 |
|
|
development process, both for the quarterly release cycles as well as
|
| 47 |
|
|
off-cycle bug and security fixes.
|
| 48 |
|
|
|
| 49 |
|
|
The Gentoo Documentation team will also be affected as they will be
|
| 50 |
|
|
responsible for updating installation documents to take these new features
|
| 51 |
|
|
into account.
|
| 52 |
|
|
|
| 53 |
|
|
Rationale
|
| 54 |
|
|
=========
|
| 55 |
|
|
|
| 56 |
|
|
A basic outline of various ways of adding a "stable" tree to Portage was
|
| 57 |
|
|
discussed in the gentoo managers meeting on 26-Jan-04. Consensus seemed to be
|
| 58 |
|
|
reached that such a solution was needed and that branching the gentoo-x86
|
| 59 |
|
|
repository was the appropriate way to accomplish this. The largest area of
|
| 60 |
|
|
disagreement surrounded how specific ebuilds should be targeted for inclusion
|
| 61 |
|
|
in the stable tree.
|
| 62 |
|
|
|
| 63 |
|
|
One suggested solution was a simple branch of the CVS tree and having
|
| 64 |
|
|
developers work in two separate branches; one for the stable tree and
|
| 65 |
|
|
another for the traditional tree. However, it was felt this would prove too
|
| 66 |
|
|
cumbersome in practice.
|
| 67 |
|
|
|
| 68 |
|
|
Another suggestion was to have a small group of dedicated gentoo-server
|
| 69 |
|
|
developers responsible for generating the contents of the stable tree, which
|
| 70 |
|
|
would provide more control and quality assurance over the ebuilds added to the
|
| 71 |
|
|
stable tree. While this might prove effective for a small number of ebuilds,
|
| 72 |
|
|
it is quite likely that this model would not scale enough to allow for a large
|
| 73 |
|
|
number of ebuilds in the stable tree and, over time, the project would become
|
| 74 |
|
|
resource constrained and unable to meed future deadlines.
|
| 75 |
|
|
|
| 76 |
|
|
The suggestion that seemed to get the most traction was the creation of a new
|
| 77 |
|
|
"stable" keyword which would be added to appropriate ebuilds. The use of
|
| 78 |
|
|
"stable" would signify ebuilds that are ready for production in the stable
|
| 79 |
g2boojum |
1.4 |
tree while "~stable" would be reserved for ebuilds which may be appropriate
|
| 80 |
klieber |
1.1 |
for the stable tree, but may require further testing before being deemed
|
| 81 |
|
|
"ready for production". Off-cycle bug fixes and/or security updates may be
|
| 82 |
klieber |
1.5 |
examples of ebuilds that require the ~stable tag.
|
| 83 |
klieber |
1.1 |
|
| 84 |
|
|
Implementation
|
| 85 |
|
|
==============
|
| 86 |
|
|
|
| 87 |
klieber |
1.3 |
While a 'stable' keyword was originally proposed, after further review, it was
|
| 88 |
|
|
determined this offered no way to allow arch-specific stable ebuilds. As
|
| 89 |
|
|
such, this GLEP proposes the use of 'stable:<arch>' and '~stable:<arch>'
|
| 90 |
|
|
(stable:x86, stable:ppc, etc.)
|
| 91 |
|
|
|
| 92 |
|
|
A new, stable tree will be created by scanning for the 'stable:<arch>' and
|
| 93 |
|
|
'~stable:<arch>' keywords in the ebuilds and pulling those ebuilds and
|
| 94 |
|
|
associated files into a separate branch of CVS. The stable tree should have
|
| 95 |
|
|
the following features:
|
| 96 |
klieber |
1.1 |
|
| 97 |
|
|
* Updated quarterly. Frozen during other times except for security/bug fixes
|
| 98 |
klieber |
1.3 |
* All ebuilds should remain in the tree for a minimum of one year. This
|
| 99 |
|
|
allows users to upgrade as infrequently as once per year without risking
|
| 100 |
|
|
the stable portage tree leaving them behind without an upgrade path.
|
| 101 |
klieber |
1.1 |
|
| 102 |
|
|
As mentioned above, the "stable" tree will be updated quarterly, ideally in
|
| 103 |
|
|
unison with the release schedule of the main Gentoo branch. This tree will be
|
| 104 |
|
|
untouched outside of this update schedule except in the following cases:
|
| 105 |
|
|
|
| 106 |
|
|
* Security fixes and patches which result in a GLSA
|
| 107 |
|
|
* Bug fixes for bugs ranked as 'maj' or above (may be overridden at the
|
| 108 |
|
|
discretion of the package maintainer.)
|
| 109 |
|
|
|
| 110 |
|
|
In both cases, the maintainer of the package will be responsible for ensuring
|
| 111 |
|
|
these patches are properly committed to the stable tree out of cycle.
|
| 112 |
|
|
|
| 113 |
|
|
Backwards Compatibility
|
| 114 |
|
|
=======================
|
| 115 |
|
|
|
| 116 |
|
|
All features proposed here are new additions to existing processes and
|
| 117 |
|
|
features. There should be no impact on existing features and functionality.
|
| 118 |
|
|
|
| 119 |
|
|
|
| 120 |
|
|
Copyright
|
| 121 |
|
|
=========
|
| 122 |
|
|
|
| 123 |
|
|
This document is licensed under the Creative Commons - Attribution / Share
|
| 124 |
|
|
Alike license. (http://creativecommons.org/licenses/by-sa/1.0)
|
Parent Directory
| 
Revision Log