Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"

[Stewart]

Stuart Bouyer wrote:
> I think you misunderstand the complaint here. The problem (which has
> been brought up this list previously) is that there is no way to
> guarantee that I can get my server back to it's current configuration if
> I have to reinstall at a later date. Not only will new versions of
> ebuilds have been added to the portage tree, but there is a great chance
> that ebuild for the version of the package that I'm happy using will no
> longer be in portage tree. What I install using the 1.3 install CD today
> will be very different from what I installed 3 months ago.

A long-standing problem is certainly the trigger-happy nature of so many 
developers when it comes to removing "old" ebuilds. I've seen it to the 
extreme where a new build was committed and all previous builds removed 
before the new version (which already had Bugzilla reports) had even 
been tested, letalone assured to be working.

I've been pushing, and plan to continue to push as hard as possible for 
a policy change where old, stable, ebuilds are concerned.

In a typical situation, we'll have builds versioned like so;

1.0
1.0-r1
1.0-r2
1.0-r3
1.1
1.1-r1
1.1-r2
1.2
1.3
2.0
2.0-r1
2.0-r2
2.0-r3

etc. ad nauseum. Current practises seem to revolve around removing all 
but the last, say, two or three ebuilds. Unfortunately, that leaves a 
/LOT/ of users in the lurch.

My contention is this; -r* builds are intended to fix problems with 
previous -r* builds (and the initial ebuild for a given version), so 
rather than removing everything <2.0, why not remove all the lowest 
numbered -r builds, thus leaving us with;

1.0-r3
1.1-r2
1.2
1.3
2.0-r3

If an ebuild is, for whatever reason, broken enough to warrant a 
revision bump, does it really conpute to leave it in the tree while 
removing a perfectly viable, if only older build in its stead?

Such a system would allow us to maintain upwards of a years' worth of 
builds in the tree without severe bloating and would permit such a 
"static version", as you've said, and would make server administrators 
rest a little easier.

A lot of talk recently about migrating Gentoo from Apache 1.3 to 2 has 
me a little frighteend. Despite assurances that 1.3 will remain in the 
tree, my observations over this past year and a half don't comfort me, 
and I, for one, am not ready (or able) to migrate all my hosting servers 
to Apache 2 just yet.

> If I don't want to update to the new package - and there are many
> reasons why I would not want to - then my only optinos are not to emerge
> sync (and miss out on the update I do need) or to manually find the
> ebuilds I want in the attic of the web cvs gateway.

Agreed completely. All too often a version change involves many late 
nights and heartburn weeding through new features and depracated 
functionality.

Projects, more often than not, will maintain security and critical 
updates for their old(er) versions for this very reason. ISC and the 
Apache Foundation are encouraging their userbase to migrate to the 
latest and greatest, for many reasons, but are in no way leaving their 
legacy customers in the lurch. Security updates to Apache 1.3 and BIND 8 
will continue indefinately (or until the use of such products is 
completely not viable). For that matter, BIND 4 still sees security 
updates when required.

If we're to move off the desktop and onto servers (or, Tux forbid, the 
Enterprise Platform) we need to allow users to stick with what works and 
track critical/security updates.

In the meantime, our best bet is to emerge -bk and store the resultant 
binaries in a centrally available location. The problems, however, with 
ebuilds dissapearing from the tree remain, so even that is imperfect.

-- 
Stewart Honsberger
http://blackdeath.snerk.org/
"Capitalists, by nature, organize to protect themselves.
-- Geeks, by nature, resist organizaion."


--
gentoo-dev@g.o mailing list