| 1 |
While all the emails regarding portage and databases are interesting, it |
| 2 |
was one of two examples of what *not* to turn this discussion into. |
| 3 |
|
| 4 |
Again, not that any of these ideas aren't good or without merit, just |
| 5 |
that this is not the topic at hand. |
| 6 |
|
| 7 |
To restate, here are some suggestions mentioned: |
| 8 |
|
| 9 |
* A frozen tree, with pre-defined update intervals. |
| 10 |
|
| 11 |
* All ebuilds in this 'frozen tree' are guaranteed to be available for a |
| 12 |
certain period of time so admins can plan their upgrades more accurately. |
| 13 |
|
| 14 |
* Multiple baselines (or tags of some kind) so new installations can use |
| 15 |
previous "releases" of the tree. Baselines will be available for X |
| 16 |
(where X is a time frame to be decided during implementation or after |
| 17 |
further research). - Paraphrased suggestion by Stephen White |
| 18 |
<steve@×××××××××××××××.au> |
| 19 |
|
| 20 |
* Ability to archive previous "release" or "snapshot" when you upgrade |
| 21 |
from one release to the next. - Paraphrased suggestion by Sebastien |
| 22 |
Arnaud <sebastien@××××××××××××××××××.com> |
| 23 |
|
| 24 |
* Updating minor versions only within a release. Example: release 2004.1 |
| 25 |
contains package-1.2.3 and will allow updates within >=package-1.2 and |
| 26 |
<package-1.3 - Paraphrased suggestion by Stephen White |
| 27 |
<steve@×××××××××××××××.au> - Note that this specifically states that |
| 28 |
packges will change between frozen releases and even if in minor |
| 29 |
versions only, behavior can (and will) change. This probably isn't |
| 30 |
suitable for the current proposal. |
| 31 |
|
| 32 |
* Method of seeing major feature / behavior changes between releases in |
| 33 |
the frozen tree. - Paraphrased suggestion by Dormando <dormando@×××××.net> |
| 34 |
|
| 35 |
Suggestions about specific implementation details such as time frames, |
| 36 |
portage command line options, and the like have been dropped for now. |
| 37 |
|
| 38 |
Notable, is a feature described by Martin Hajduch where he talks about a |
| 39 |
way of filtering or creating profiles of packages (easily, because yes, |
| 40 |
it can currently be done, but it's a pain to maintain). Essentially, to |
| 41 |
paraphrase, he suggested a method of creating your own portage (read: |
| 42 |
ebuild) sets or snapshots. The reason this is not listed as a suggestion |
| 43 |
above is because it's more of a portage feature than a frozen tree |
| 44 |
attribute. |
| 45 |
|
| 46 |
Things to remember (i.e. what this proposal is not about): |
| 47 |
|
| 48 |
* Security updates will always be pushed into the frozen tree between |
| 49 |
releases so special flags such as --security-only would not be required |
| 50 |
because any new packages would be security related. |
| 51 |
|
| 52 |
* Gentoo sponsored back porting isn't in the cards. We don't have the |
| 53 |
dev-power to do so. If upstream maintainers backport security fixes in |
| 54 |
their packages, they would (presumably) be released as security updates |
| 55 |
(see above). |
| 56 |
|
| 57 |
So, further discussion in terms of features for this proposal is |
| 58 |
invited. Again, please try and avoid implementation issues (i.e. the |
| 59 |
command should be '--foo', 30 days vs. 31, cvs branches vs. tarballs, |
| 60 |
etc.) and features that are about portage itself (database backends, |
| 61 |
security only updates). |
| 62 |
|
| 63 |
Regards. |
| 64 |
-- |
| 65 |
Eric Sammer |
| 66 |
Gentoo Linux |
| 67 |
http://www.gentoo.org |
Archives