| 1 |
Hi! |
| 2 |
|
| 3 |
On Wed, Aug 16, 2006 at 09:16:55AM -0500, Jesse, Rich wrote: |
| 4 |
> Constant and needless updating servers is the exact opposite of "stable". |
| 5 |
|
| 6 |
Yeah. |
| 7 |
|
| 8 |
But last years show ARCH=x86 is stable enough and such updates |
| 9 |
very rare broke anything, so "constant" in this case doesn't result in |
| 10 |
so many troubles as it sounds. |
| 11 |
|
| 12 |
About "needless" - as I said before, in last years I've tried all ways |
| 13 |
to update servers - exactly because I also wanna install only security |
| 14 |
fixes for everything plus sometimes update some critical for my tasks |
| 15 |
packages because of important bug fixes there... but this doesn't work |
| 16 |
in long term, :( while "constant updating" solve these issues without |
| 17 |
introducing too many new problems. |
| 18 |
|
| 19 |
> By default, Portage doesn't lend itself to this. I don't need/want the |
| 20 |
> latest Postgres just because it's available, especially when the upgrade |
| 21 |
> would require data and/or app migration. Upgrades warrant testing. I |
| 22 |
> can't justify spend hundreds of man-hours testing all available apps on |
| 23 |
> a given system just because some program went from v4.3 to 4.3-1. |
| 24 |
|
| 25 |
Hmm... Again, x86 is stable enough to avoid such retesting on each update. |
| 26 |
I agree it's nice idea to retest everything, but it's just impossible - |
| 27 |
you should define some intelligent amount of retesting which you able to |
| 28 |
do quickly after update. Something like smoke testing in few clicks to be |
| 29 |
sure your app is running and working with database is enough for most cases. |
| 30 |
If some deeper problems arise in this app just because of database update |
| 31 |
from 4.3 to 4.3.1 then it's probably because of bug in your app and it's |
| 32 |
better to fix it NOW. |
| 33 |
|
| 34 |
Probably this way isn't acceptable for you - I'm mostly administrate |
| 35 |
servers dedicated for few complex apps, and it's ease to quickly check |
| 36 |
them all after update. |
| 37 |
|
| 38 |
Also, I don't think your example is good and realistic. So critical |
| 39 |
components as database isn't update often, newer version of databases |
| 40 |
isn't usually marked as dependency for some other app, so you usually |
| 41 |
isn't forced to update it ASAP - you can delay database update until |
| 42 |
you'll read changelog and become sure your apps are ready for it. |
| 43 |
|
| 44 |
> I also can't justify upgrading just because Gentoo no longer wants to |
| 45 |
> keep last year's ebuild around. Thankfully, a sysadmin can make use of |
| 46 |
> OVERLAY and rsync (*without* "--delete"!) to create their own portage |
| 47 |
> tree, complete with all the old rebuilds. Anyone that's tried to |
| 48 |
> upgrade an old OpenSSH knows what happens on the ensuing revdep-rebuild |
| 49 |
> -- ebuilds are gone, and you're stuck in the mud. |
| 50 |
|
| 51 |
Yeah, I know. But removing --delete doesn't guaranty ability to install |
| 52 |
old ebuild - just because ebuilds sometimes changed without versions |
| 53 |
bumping, and reinstalling same version few months later can result in |
| 54 |
compilation using different patches and/or configure options, etc. |
| 55 |
|
| 56 |
Such "old" ebuild even can fail to unpack, see this example: |
| 57 |
1) [January] foo-1.0.ebuild added, it use files/foo.patch |
| 58 |
2) [Febrary] foo-1.0.ebuild deleted, |
| 59 |
foo-2.0.ebuild added, it also use files/foo.patch, but this |
| 60 |
is completely different patch while it has same name as |
| 61 |
previous patch :( |
| 62 |
|
| 63 |
And another problem: removing old ebuild from portage mean it isn't |
| 64 |
supported anymore, so you doesn't get GLSA and bugfixes for it. This is |
| 65 |
why naive initiative of Jan Meier (in second subthread of this thread) |
| 66 |
will not work: |
| 67 |
|
| 68 |
>> I think every update because of security reasons has a security announcement. |
| 69 |
>> |
| 70 |
>> I would be willing to start such a stable tree, I am thinking of taking a |
| 71 |
>> current portage tree, delete all ~arch ebuilds and create an overlay. Every |
| 72 |
>> time a security announcement is fired up I will add the newer ebuild to the |
| 73 |
>> overlay, checking for any really needed depencies. |
| 74 |
|
| 75 |
> But that doesn't mean I don't need stability. Any major libs get |
| 76 |
> changed and I need to relink Oracle. Then I need to wonder what changed |
| 77 |
|
| 78 |
Yeah, but... there always some reason why things like glibc updates, and |
| 79 |
you free to update it or delay update because you don't have time now |
| 80 |
to relink Oracle. |
| 81 |
|
| 82 |
There is a big difference between 'install only selected updates' and |
| 83 |
'install all updates except selected'. I prefer second because first |
| 84 |
don't work in long term (I got troubles installing security updates after |
| 85 |
about 6-8 months going this way). To support first way and get 'stable |
| 86 |
portage tree' we need big enough team of Gentoo devs dedicated for this |
| 87 |
task. For now it doesn't looks like they willing to do this. |
| 88 |
|
| 89 |
Maybe 'Debian stable' is right choice for ppl who vote for 'stable |
| 90 |
portage tree' - it has only very old, really stable packages and only |
| 91 |
critical updates (I doesn't use Debian myself, so maybe I'm wrong about it). |
| 92 |
|
| 93 |
> I'm way short on time and way too terse here. This is the kinda stuff |
| 94 |
> that needs to be debated over copius amounts of really freakin good |
| 95 |
> beer. |
| 96 |
|
| 97 |
Agreed! :) |
| 98 |
|
| 99 |
-- |
| 100 |
WBR, Alex. |
| 101 |
-- |
| 102 |
gentoo-server@g.o mailing list |
Archives