1 |
I have been emailing the published addresses for GLEP 19 for 2 months now |
2 |
with no success. I am very interested in any ideas or projects that might |
3 |
help gentoo be more server friendly, in an "enterprise" environment, for |
4 |
lack of a better term. |
5 |
|
6 |
I have an idea towards "stabilizing" portage for production environments, |
7 |
but I am not knowledgeable enough about portage to know if it would even be |
8 |
plausible. If this is the wrong place to ask this, please feel free to |
9 |
point me in a better direction. |
10 |
|
11 |
Basically, add a new value for "FEATURES". For lack of a better name, call |
12 |
it "sticky". |
13 |
|
14 |
FEATURES="sticky" |
15 |
|
16 |
If this flag is present in make.conf: |
17 |
|
18 |
1) emerge --sync does only updates, not deletes (don't ditch old ebuilds). |
19 |
|
20 |
2) Implement a new revision numbering scheme for ebuilds, -sX. Similar to |
21 |
-rX, but for glsa updates only. It could be an abbreviation for sticky, |
22 |
security, or stable, whatever you want. |
23 |
|
24 |
For example if I am currently running mysql-4.0.25, the only candidate an |
25 |
emerge -u would consider would be mysql-4.0.25-s1, mysql-4.0.25-s2, etc.... |
26 |
In other words, emerge considers only -sX in its upgrade calculations, |
27 |
instead of -rX, and only considers the same version. |
28 |
|
29 |
3) Package maintainers could create duplicate ebuilds for security-only |
30 |
related revisions to packages, some other team could maintain them, this be |
31 |
somehow automated, or this could be left up to the users to maintain |
32 |
through their own overlays. My idea is fuzzy here... |
33 |
|
34 |
4) In cases where a vulnerability exists that can only be addressed by |
35 |
bumping up to the next version, leave it up to the user to upgrade to it |
36 |
manually (FEATURES="-sticky" emerge -u mysql). |
37 |
|
38 |
Plausible? |