1 |
klieber |
1.2 |
GLEP: 19 |
2 |
|
|
Title: Gentoo Stable Portage Tree |
3 |
klieber |
1.7 |
Version: $Revision: 1.7 $ |
4 |
|
|
Last-Modified: $Date: 2004/11/02 15:38:58 $ |
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 |
klieber |
1.7 |
Post-History: 29-Jan-2004 2-Nov-2004 7-Dec-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 |
klieber |
1.7 |
While the original draft of this GLEP called for the creation of a stable |
77 |
|
|
keyword, we have since discarded that idea in favor of creating a custom |
78 |
|
|
profile, which will be used to track a subset of packages and versions. |
79 |
klieber |
1.1 |
|
80 |
|
|
Implementation |
81 |
|
|
============== |
82 |
|
|
|
83 |
klieber |
1.7 |
This GLEP will create a new set of cascaded profiles (one per release, not to |
84 |
|
|
exceed two per year) which will contain a subset of packages, including |
85 |
|
|
versions. This profile will "pin" a Gentoo Linux box to a specific set of |
86 |
|
|
packages and will only be updated for security updates and, in rare |
87 |
|
|
circumstances, major bug fixes. |
88 |
|
|
|
89 |
|
|
Because this profile will be cascaded, the option exists for other developers |
90 |
|
|
to create their own profile, containing a subset of packages not found in the |
91 |
|
|
"main" stable tree and include those as part of the overall stable profile. |
92 |
|
|
These cases will be treated on a one-off basis. |
93 |
|
|
|
94 |
|
|
The initial version will be x86 only, though other people will be encouraged |
95 |
|
|
to provide separate stable profiles for other arches. It is expected that any |
96 |
|
|
effort to provide a stable tree for any arch or flavor of Gentoo will follow |
97 |
|
|
the basic outline of this GLEP to ensure consistency for our users. |
98 |
|
|
|
99 |
|
|
In addition to a custom profile, this GLEP will also create a separate rsync |
100 |
|
|
repository, "gentoo-stable-portage", which will be available on all servers in |
101 |
|
|
the rsync.gentoo.org rotation. This repository will be *identical* to the |
102 |
|
|
main gentoo-portage repository except that the --delete flag will be removed |
103 |
|
|
from the rsync option that populates the tree. This will ensure that users of |
104 |
|
|
the stable profile will not have to worry about ebuilds for their packages |
105 |
|
|
disappearing. |
106 |
|
|
|
107 |
|
|
Stable profiles will be maintained on an N - 2 basis. That is to say that we |
108 |
|
|
will maintain a stable profile for the most current release, plus the previous |
109 |
|
|
two releases. With the expected release schedule for 2005, this will result |
110 |
|
|
in each profile being supported for approximately 18 months. Future versions |
111 |
|
|
of the stable portage tree may seek to increase the life of these profiles. |
112 |
klieber |
1.1 |
|
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) |