| 1 | GLEP: 19 |
1 | GLEP: 19 |
| 2 | Title: Gentoo Stable Portage Tree |
2 | Title: Gentoo Stable Portage Tree |
| 3 | Version: $Revision: 1.2 $ |
3 | Version: $Revision: 1.7 $ |
| 4 | Last-Modified: $Date: 2004/01/27 01:55:37 $ |
4 | Last-Modified: $Date: 2004/12/08 00:24:23 $ |
| 5 | Author: Kurt Lieber <klieber@gentoo.org> |
5 | Author: Kurt Lieber <klieber@gentoo.org> |
| 6 | Status: Draft |
6 | Status: Draft |
| 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 |
| 11 | |
11 | |
| 12 | |
12 | |
| 13 | Abstract |
13 | Abstract |
| 14 | ======== |
14 | ======== |
| 15 | |
15 | |
| … | |
… | |
| 20 | |
20 | |
| 21 | The proposed solution involves creating a separate tree in Portage that is |
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, |
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. |
23 | this tree would only be updated with critical bugfixes and security patches. |
| 24 | |
24 | |
|
|
25 | Status |
|
|
26 | ====== |
|
|
27 | |
|
|
28 | Currently recruiting people who would be willing to help with this GLEP. |
|
|
29 | |
| 25 | Motivation |
30 | Motivation |
| 26 | ========== |
31 | ========== |
| 27 | |
32 | |
| 28 | Enterprise customers typically value stability and a predictable upgrade path |
33 | Enterprise users typically value stability and a predictable upgrade path |
| 29 | over having the latest packages or features available to them. Historically, |
34 | 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 |
35 | Gentoo Linux has been unable to provide such an environment due to the dynamic |
| 31 | nature of the Portage tree. |
36 | nature of the Portage tree. |
| 32 | |
37 | |
| 33 | Specification |
38 | Specification |
| … | |
… | |
| 66 | stable tree. While this might prove effective for a small number of ebuilds, |
71 | 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 |
72 | 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 |
73 | number of ebuilds in the stable tree and, over time, the project would become |
| 69 | resource constrained and unable to meed future deadlines. |
74 | resource constrained and unable to meed future deadlines. |
| 70 | |
75 | |
| 71 | The suggestion that seemed to get the most traction was the creation of a new |
76 | 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 |
77 | 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 |
78 | 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 | |
79 | |
| 79 | Implementation |
80 | Implementation |
| 80 | ============== |
81 | ============== |
| 81 | |
82 | |
| 82 | A new, stable tree will be created by scanning for the 'server' and '~server' |
83 | 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 |
84 | 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: |
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. |
| 85 | |
88 | |
| 86 | * Updated quarterly. Frozen during other times except for security/bug fixes |
89 | 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 |
90 | 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 |
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. |
| 89 | |
93 | |
| 90 | As mentioned above, the "stable" tree will be updated quarterly, ideally in |
94 | 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 |
95 | 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: |
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. |
| 93 | |
98 | |
| 94 | * Security fixes and patches which result in a GLSA |
99 | 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 |
100 | repository, "gentoo-stable-portage", which will be available on all servers in |
| 96 | discretion of the package maintainer.) |
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. |
| 97 | |
106 | |
| 98 | In both cases, the maintainer of the package will be responsible for ensuring |
107 | 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. |
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. |
| 100 | |
112 | |
| 101 | Backwards Compatibility |
113 | Backwards Compatibility |
| 102 | ======================= |
114 | ======================= |
| 103 | |
115 | |
| 104 | All features proposed here are new additions to existing processes and |
116 | All features proposed here are new additions to existing processes and |
Parent Directory
| 
Revision Log
| 
Patch