| 1 | GLEP: 19 |
1 | GLEP: 19 |
| 2 | Title: Gentoo Stable Portage Tree |
2 | Title: Gentoo Stable Portage Tree |
| 3 | Version: $Revision: 1.6 $ |
3 | Version: $Revision: 1.7 $ |
| 4 | Last-Modified: $Date: 2004/11/02 15:38:58 $ |
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: 29-Jan-2004 2-Nov-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 | |
| … | |
… | |
| 71 | 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, |
| 72 | 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 |
| 73 | 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 |
| 74 | resource constrained and unable to meed future deadlines. |
74 | resource constrained and unable to meed future deadlines. |
| 75 | |
75 | |
| 76 | 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 |
| 77 | "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 |
| 78 | "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. |
| 79 | tree while "~stable" would be reserved for ebuilds which may be appropriate |
|
|
| 80 | 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 | examples of ebuilds that require the ~stable tag. |
|
|
| 83 | |
79 | |
| 84 | Implementation |
80 | Implementation |
| 85 | ============== |
81 | ============== |
| 86 | |
82 | |
| 87 | While a 'stable' keyword was originally proposed, after further review, it was |
83 | This GLEP will create a new set of cascaded profiles (one per release, not to |
| 88 | determined this offered no way to allow arch-specific stable ebuilds. As |
84 | exceed two per year) which will contain a subset of packages, including |
| 89 | such, this GLEP proposes the use of 'stable:<arch>' and '~stable:<arch>' |
85 | versions. This profile will "pin" a Gentoo Linux box to a specific set of |
| 90 | (stable:x86, stable:ppc, etc.) |
86 | packages and will only be updated for security updates and, in rare |
|
|
87 | circumstances, major bug fixes. |
| 91 | |
88 | |
| 92 | A new, stable tree will be created by scanning for the 'stable:<arch>' and |
89 | Because this profile will be cascaded, the option exists for other developers |
| 93 | '~stable:<arch>' keywords in the ebuilds and pulling those ebuilds and |
90 | to create their own profile, containing a subset of packages not found in the |
| 94 | associated files into a separate branch of CVS. The stable tree should have |
91 | "main" stable tree and include those as part of the overall stable profile. |
| 95 | the following features: |
92 | These cases will be treated on a one-off basis. |
| 96 | |
93 | |
| 97 | * Updated quarterly. Frozen during other times except for security/bug fixes |
94 | The initial version will be x86 only, though other people will be encouraged |
| 98 | * All ebuilds should remain in the tree for a minimum of one year. This |
95 | to provide separate stable profiles for other arches. It is expected that any |
| 99 | allows users to upgrade as infrequently as once per year without risking |
96 | effort to provide a stable tree for any arch or flavor of Gentoo will follow |
| 100 | the stable portage tree leaving them behind without an upgrade path. |
97 | the basic outline of this GLEP to ensure consistency for our users. |
| 101 | |
98 | |
| 102 | As mentioned above, the "stable" tree will be updated quarterly, ideally in |
99 | In addition to a custom profile, this GLEP will also create a separate rsync |
| 103 | unison with the release schedule of the main Gentoo branch. This tree will be |
100 | repository, "gentoo-stable-portage", which will be available on all servers in |
| 104 | untouched outside of this update schedule except in the following cases: |
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. |
| 105 | |
106 | |
| 106 | * Security fixes and patches which result in a GLSA |
107 | Stable profiles will be maintained on an N - 2 basis. That is to say that we |
| 107 | * Bug fixes for bugs ranked as 'maj' or above (may be overridden at the |
108 | will maintain a stable profile for the most current release, plus the previous |
| 108 | discretion of the package maintainer.) |
109 | two releases. With the expected release schedule for 2005, this will result |
| 109 | |
110 | in each profile being supported for approximately 18 months. Future versions |
| 110 | In both cases, the maintainer of the package will be responsible for ensuring |
111 | of the stable portage tree may seek to increase the life of these profiles. |
| 111 | these patches are properly committed to the stable tree out of cycle. |
|
|
| 112 | |
112 | |
| 113 | Backwards Compatibility |
113 | Backwards Compatibility |
| 114 | ======================= |
114 | ======================= |
| 115 | |
115 | |
| 116 | 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