| 1 |
> I have never really looked into how portage is made up to deeply but I |
| 2 |
> would imagine that doing |
| 3 |
> number 2 would have the most benefit and if you are using cvs as I |
| 4 |
> think you are then you might be |
| 5 |
> able to just have a different branch in the tree that has like a 6 |
| 6 |
> month life span. By default you would get |
| 7 |
> the bleeding edge stuff so that it gets tested more but for those who |
| 8 |
> needed a slower moving target |
| 9 |
> they could just change the module they are rsyncing too from |
| 10 |
> gentoo-portage to gentoo-stable-portage |
| 11 |
> or something like that. |
| 12 |
|
| 13 |
excuse the stupid question: |
| 14 |
what's the purpose of 'x86' arch tree then ? i though that this one |
| 15 |
should be stable, slowly moving tree, at least comparing |
| 16 |
to '~x86' ? |
| 17 |
|
| 18 |
i'm running gentoo on some servers, as many others are doing |
| 19 |
i have tried to use 'x86' first but i have discovered that i need some |
| 20 |
packages from '~x86', so i moved to '~x86' and i'm trying to be careful |
| 21 |
and update only things which i need to update |
| 22 |
|
| 23 |
while it may be good to have maintained tree for servers, i'm not sure |
| 24 |
if you can setup a server/enterprise tree which would suit everyone's needs |
| 25 |
i mean -> i need some packages from '~x86', other people may need |
| 26 |
another packages and at the end, after merging all such requests, you may |
| 27 |
end up with more or less an exact copy of current '~x86' |
| 28 |
|
| 29 |
thinking about it a little bit more, i would prefer to have an easy way |
| 30 |
of configuring what i want to update, and what not |
| 31 |
i mean - i install a server with certain versions of packages (coming |
| 32 |
from '~x86' in some time in the past) - i test everything and i'm happy |
| 33 |
with this installation; i don't want to get regular updates on most of |
| 34 |
the packages (i can always do such updates manually, can't i ?) |
| 35 |
then there are couple of packages/ebuilds which i want to always upgrade |
| 36 |
to the latest version |
| 37 |
and of course, i want to get all security upgrades plus dependent |
| 38 |
packages (if the security upgrade is not backported, i have no other way |
| 39 |
then just |
| 40 |
upgrade the whole dependency tree ...) |
| 41 |
|
| 42 |
so if i could write into a configuration file something like: 'keep |
| 43 |
current versions of all packages, except packages a, b, c; but give me |
| 44 |
all SECURITY upgrades' - it would be great |
| 45 |
|
| 46 |
in addition; it would be good if the security updates (ebuilds) could be |
| 47 |
version-less (to certain extent ...) |
| 48 |
imagine this, you have package called PKG, installed on different |
| 49 |
servers in versions 1.1, 1.2, 1.3 |
| 50 |
now, a security problem is found and patch released, this patch can be |
| 51 |
applied to 1.2 and 1.3 |
| 52 |
so there will be an ebuild, which would: |
| 53 |
- if 1.1 is installed, it would ask user to upgrade either to 1.2 or 1.3 |
| 54 |
first |
| 55 |
- if 1.2 is installed, it would recompile 1.2 with security patch |
| 56 |
applied, and somehow mark the version installed to 1.2_including_patch_XYZ |
| 57 |
- if 1.3 is installed, it would recompile 1.3 with security patch |
| 58 |
applied, and somehow mark the version installed to 1.3_including_patch_XYZ |
| 59 |
|
| 60 |
it is clear that noone is going to backport security upgrades to all |
| 61 |
versions possible, but usually you can easily patch couple of last versions |
| 62 |
|
| 63 |
another approach is to define something like: |
| 64 |
openssh: x86 |
| 65 |
openssl: x86 |
| 66 |
apache: ~x86 |
| 67 |
etc ... |
| 68 |
|
| 69 |
if something of this is already possible, i would appreciate any |
| 70 |
pointers on how to achieve this |
| 71 |
|
| 72 |
thanks, |
| 73 |
martin |
Archives