From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4803 invoked by uid 1002); 26 Jun 2003 16:46:03 -0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 1282 invoked from network); 26 Jun 2003 16:46:03 -0000 Message-ID: <3EFB2350.3010603@snerk.org> Date: Thu, 26 Jun 2003 12:46:08 -0400 From: Stewart Organization: Snerk World Enterprises User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030617 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev@gentoo.org Cc: Stuart Bouyer References: <20030624005813.GA5061@cerberus.oppresses.us> <20030624031603.6ddf9456.xwred1@xwredwing.net> <20030624171810.GA11676@cerberus.oppresses.us> <20030624162733.26377e48.xwred1@xwredwing.net> <20030625003039.GB25581@cerberus.oppresses.us> <20030624212200.29afd907.xwred1@xwredwing.net> <20030625041956.GA27580@cerberus.oppresses.us> <20030624214904.4a08cefb.xwred1@xwredwing.net> <20030625045343.GA27897@cerberus.oppresses.us> <20030624221257.50aab7c5.xwred1@xwredwing.net> <20030625051527.GA28137@cerberus.oppresses.us> <62420000.1056535645@localhost> <20030625042245.6d729118.xwred1@xwredwing.net> <181950000.1056547091@localhost> <20030625230844.41f8121f.stubear@bouyer.no-ip.org> In-Reply-To: <20030625230844.41f8121f.stubear@bouyer.no-ip.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] Gentoo Weekly News Letter - "Where is Gentoo Linux 1.4" X-Archives-Salt: abc31351-8d26-4ec4-96aa-8839da988370 X-Archives-Hash: 2069514a6b5de8487aa9d1b87ee3e3e1 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@gentoo.org mailing list