Gentoo Archives: gentoo-dev

From: Stewart <bdlists@×××××.org>
To: gentoo-dev@g.o
Cc: Stuart Bouyer <stubear@××××××××××××.org>
Subject: Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4"
Date: Thu, 26 Jun 2003 16:46:03
In Reply to: Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4" by Stuart Bouyer
1 Stuart Bouyer wrote:
2 > I think you misunderstand the complaint here. The problem (which has
3 > been brought up this list previously) is that there is no way to
4 > guarantee that I can get my server back to it's current configuration if
5 > I have to reinstall at a later date. Not only will new versions of
6 > ebuilds have been added to the portage tree, but there is a great chance
7 > that ebuild for the version of the package that I'm happy using will no
8 > longer be in portage tree. What I install using the 1.3 install CD today
9 > will be very different from what I installed 3 months ago.
11 A long-standing problem is certainly the trigger-happy nature of so many
12 developers when it comes to removing "old" ebuilds. I've seen it to the
13 extreme where a new build was committed and all previous builds removed
14 before the new version (which already had Bugzilla reports) had even
15 been tested, letalone assured to be working.
17 I've been pushing, and plan to continue to push as hard as possible for
18 a policy change where old, stable, ebuilds are concerned.
20 In a typical situation, we'll have builds versioned like so;
22 1.0
23 1.0-r1
24 1.0-r2
25 1.0-r3
26 1.1
27 1.1-r1
28 1.1-r2
29 1.2
30 1.3
31 2.0
32 2.0-r1
33 2.0-r2
34 2.0-r3
36 etc. ad nauseum. Current practises seem to revolve around removing all
37 but the last, say, two or three ebuilds. Unfortunately, that leaves a
38 /LOT/ of users in the lurch.
40 My contention is this; -r* builds are intended to fix problems with
41 previous -r* builds (and the initial ebuild for a given version), so
42 rather than removing everything <2.0, why not remove all the lowest
43 numbered -r builds, thus leaving us with;
45 1.0-r3
46 1.1-r2
47 1.2
48 1.3
49 2.0-r3
51 If an ebuild is, for whatever reason, broken enough to warrant a
52 revision bump, does it really conpute to leave it in the tree while
53 removing a perfectly viable, if only older build in its stead?
55 Such a system would allow us to maintain upwards of a years' worth of
56 builds in the tree without severe bloating and would permit such a
57 "static version", as you've said, and would make server administrators
58 rest a little easier.
60 A lot of talk recently about migrating Gentoo from Apache 1.3 to 2 has
61 me a little frighteend. Despite assurances that 1.3 will remain in the
62 tree, my observations over this past year and a half don't comfort me,
63 and I, for one, am not ready (or able) to migrate all my hosting servers
64 to Apache 2 just yet.
66 > If I don't want to update to the new package - and there are many
67 > reasons why I would not want to - then my only optinos are not to emerge
68 > sync (and miss out on the update I do need) or to manually find the
69 > ebuilds I want in the attic of the web cvs gateway.
71 Agreed completely. All too often a version change involves many late
72 nights and heartburn weeding through new features and depracated
73 functionality.
75 Projects, more often than not, will maintain security and critical
76 updates for their old(er) versions for this very reason. ISC and the
77 Apache Foundation are encouraging their userbase to migrate to the
78 latest and greatest, for many reasons, but are in no way leaving their
79 legacy customers in the lurch. Security updates to Apache 1.3 and BIND 8
80 will continue indefinately (or until the use of such products is
81 completely not viable). For that matter, BIND 4 still sees security
82 updates when required.
84 If we're to move off the desktop and onto servers (or, Tux forbid, the
85 Enterprise Platform) we need to allow users to stick with what works and
86 track critical/security updates.
88 In the meantime, our best bet is to emerge -bk and store the resultant
89 binaries in a centrally available location. The problems, however, with
90 ebuilds dissapearing from the tree remain, so even that is imperfect.
92 --
93 Stewart Honsberger
95 "Capitalists, by nature, organize to protect themselves.
96 -- Geeks, by nature, resist organizaion."
99 --
100 gentoo-dev@g.o mailing list


Subject Author
Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4" Georgi Georgiev <chutz@×××.net>
Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4" Jonathan Kelly <jonkelly@××××××××××××.au>