| 1 |
Chris Gianelloni <wolf31o2@g.o> writes: |
| 2 |
|
| 3 |
> [snip] |
| 4 |
|
| 5 |
> So we move no closer to our goal of providing a stable/frozen |
| 6 |
> installation environment than to ensure ebuilds don't disappear from the |
| 7 |
> tree? How is this really beneficial to our users? Is there a reason |
| 8 |
> for completely separating the idea of a "stable" tree from our already |
| 9 |
> established releases? Is there a reason why they cannot both be |
| 10 |
> modified to work together and do what is best for our users, gives them |
| 11 |
> the most choice, and gives them what they're actually asking for? |
| 12 |
|
| 13 |
If we make sure to follow the convention throughout the tree that |
| 14 |
revisions are only used for bug fixes (which is essentially the current |
| 15 |
convention, with a few exceptions), then a `stable' release profile |
| 16 |
could be automatically generated from the normal release profile using |
| 17 |
an automated tool that, for every package included in the release, |
| 18 |
simply hard masks later versions (but not later revisions) of the |
| 19 |
package. |
| 20 |
|
| 21 |
If it is desirable that future packages added to the tree be blocked as |
| 22 |
well, the `stable' profiles could be augmented with a file that would |
| 23 |
limit the user to only those packages listed in this file. |
| 24 |
|
| 25 |
-- |
| 26 |
Jeremy Maitin-Shepard |
Archives