| 1 | GLEP: 18 |
1 | GLEP: 19 |
| 2 | Title: Gentoo Bimonthly Publication |
2 | Title: Gentoo Stable Portage Tree |
| 3 | Version: $Revision: 1.1 $ |
3 | Version: $Revision: 1.8 $ |
| 4 | Last-Modified: $Date: 2004/01/27 01:50:51 $ |
4 | Last-Modified: $Date: 2006/10/10 16:54:34 $ |
| 5 | Author: Kurt Lieber <klieber@gentoo.org> |
5 | Author: Kurt Lieber <klieber@gentoo.org> |
| 6 | Status: Draft |
6 | Status: Withdrawn |
| 7 | Type: Standards Track |
7 | Type: Standards Track |
| 8 | Content-Type: text/x-rst |
8 | Content-Type: text/x-rst |
| 9 | Created: 26-Jan-2004 |
9 | Created: 26-Jan-2004 |
| 10 | Post-History: 26-Jan-2004 |
10 | Post-History: 29-Jan-2004 2-Nov-2004 7-Dec-2004 10-Oct-2006 |
| 11 | |
11 | |
|
|
12 | Status |
|
|
13 | ====== |
|
|
14 | |
|
|
15 | Withdrawn by the author. "If someone wants to take up the torch, more |
|
|
16 | power to them, but they should probably start clean with a new glep." |
| 12 | |
17 | |
| 13 | Abstract |
18 | Abstract |
| 14 | ======== |
19 | ======== |
| 15 | |
20 | |
| 16 | This GLEP is intended to propose a series of changes to the Portage tree that |
21 | This GLEP is intended to propose a series of changes to the Portage tree that |
| … | |
… | |
| 20 | |
25 | |
| 21 | The proposed solution involves creating a separate tree in Portage that is |
26 | 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, |
27 | 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. |
28 | this tree would only be updated with critical bugfixes and security patches. |
| 24 | |
29 | |
|
|
30 | Status |
|
|
31 | ====== |
|
|
32 | |
|
|
33 | Currently recruiting people who would be willing to help with this GLEP. |
|
|
34 | |
| 25 | Motivation |
35 | Motivation |
| 26 | ========== |
36 | ========== |
| 27 | |
37 | |
| 28 | Enterprise customers typically value stability and a predictable upgrade path |
38 | Enterprise users typically value stability and a predictable upgrade path |
| 29 | over having the latest packages or features available to them. Historically, |
39 | over having the latest packages or features available to them. Historically, |
| 30 | Gentoo Linux has been unable to provide such an environment due to the dynamic |
40 | Gentoo Linux has been unable to provide such an environment due to the dynamic |
| 31 | nature of the Portage tree. |
41 | nature of the Portage tree. |
| 32 | |
42 | |
| 33 | Specification |
43 | Specification |
| … | |
… | |
| 66 | stable tree. While this might prove effective for a small number of ebuilds, |
76 | stable tree. While this might prove effective for a small number of ebuilds, |
| 67 | it is quite likely that this model would not scale enough to allow for a large |
77 | it is quite likely that this model would not scale enough to allow for a large |
| 68 | number of ebuilds in the stable tree and, over time, the project would become |
78 | number of ebuilds in the stable tree and, over time, the project would become |
| 69 | resource constrained and unable to meed future deadlines. |
79 | resource constrained and unable to meed future deadlines. |
| 70 | |
80 | |
| 71 | The suggestion that seemed to get the most traction was the creation of a new |
81 | While the original draft of this GLEP called for the creation of a stable |
| 72 | "stable" keyword which would be added to appropriate ebuilds. The use of |
82 | keyword, we have since discarded that idea in favor of creating a custom |
| 73 | "stable" would signify ebuilds that are ready for production in the stable |
83 | profile, which will be used to track a subset of packages and versions. |
| 74 | tree whils "~stable" would be reserved for ebuilds which may be appropriate |
|
|
| 75 | for the stable tree, but may require further testing before being deemed |
|
|
| 76 | "ready for production". Off-cycle bug fixes and/or security updates may be |
|
|
| 77 | examples of ebuilds that require the ~server tag. |
|
|
| 78 | |
84 | |
| 79 | Implementation |
85 | Implementation |
| 80 | ============== |
86 | ============== |
| 81 | |
87 | |
| 82 | A new, stable tree will be created by scanning for the 'server' and '~server' |
88 | This GLEP will create a new set of cascaded profiles (one per release, not to |
| 83 | keywords in the ebuilds and pulling those ebuilds and associated files into a |
89 | exceed two per year) which will contain a subset of packages, including |
| 84 | separate branch of CVS. The stable tree should have the following features: |
90 | versions. This profile will "pin" a Gentoo Linux box to a specific set of |
|
|
91 | packages and will only be updated for security updates and, in rare |
|
|
92 | circumstances, major bug fixes. |
| 85 | |
93 | |
| 86 | * Updated quarterly. Frozen during other times except for security/bug fixes |
94 | Because this profile will be cascaded, the option exists for other developers |
| 87 | * All ebuilds should remain in the tree for a minimum of one year to ensure |
95 | to create their own profile, containing a subset of packages not found in the |
| 88 | that administrators will know how often their servers need to be upgraded |
96 | "main" stable tree and include those as part of the overall stable profile. |
|
|
97 | These cases will be treated on a one-off basis. |
| 89 | |
98 | |
| 90 | As mentioned above, the "stable" tree will be updated quarterly, ideally in |
99 | The initial version will be x86 only, though other people will be encouraged |
| 91 | unison with the release schedule of the main Gentoo branch. This tree will be |
100 | to provide separate stable profiles for other arches. It is expected that any |
| 92 | untouched outside of this update schedule except in the following cases: |
101 | effort to provide a stable tree for any arch or flavor of Gentoo will follow |
|
|
102 | the basic outline of this GLEP to ensure consistency for our users. |
| 93 | |
103 | |
| 94 | * Security fixes and patches which result in a GLSA |
104 | In addition to a custom profile, this GLEP will also create a separate rsync |
| 95 | * Bug fixes for bugs ranked as 'maj' or above (may be overridden at the |
105 | repository, "gentoo-stable-portage", which will be available on all servers in |
| 96 | discretion of the package maintainer.) |
106 | the rsync.gentoo.org rotation. This repository will be *identical* to the |
|
|
107 | main gentoo-portage repository except that the --delete flag will be removed |
|
|
108 | from the rsync option that populates the tree. This will ensure that users of |
|
|
109 | the stable profile will not have to worry about ebuilds for their packages |
|
|
110 | disappearing. |
| 97 | |
111 | |
| 98 | In both cases, the maintainer of the package will be responsible for ensuring |
112 | Stable profiles will be maintained on an N - 2 basis. That is to say that we |
| 99 | these patches are properly committed to the stable tree out of cycle. |
113 | will maintain a stable profile for the most current release, plus the previous |
|
|
114 | two releases. With the expected release schedule for 2005, this will result |
|
|
115 | in each profile being supported for approximately 18 months. Future versions |
|
|
116 | of the stable portage tree may seek to increase the life of these profiles. |
| 100 | |
117 | |
| 101 | Backwards Compatibility |
118 | Backwards Compatibility |
| 102 | ======================= |
119 | ======================= |
| 103 | |
120 | |
| 104 | All features proposed here are new additions to existing processes and |
121 | All features proposed here are new additions to existing processes and |
Parent Directory
| 
Revision Log
| 
Patch