From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev-return-14253-arch-gentoo-dev=gentoo.org@lists.gentoo.org> Received: (qmail 26983 invoked from network); 21 Jul 2004 03:10:49 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 21 Jul 2004 03:10:49 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1Bn7VH-0008VM-UT for arch-gentoo-dev@lists.gentoo.org; Wed, 21 Jul 2004 03:10:48 +0000 Received: (qmail 4630 invoked by uid 89); 21 Jul 2004 03:10:46 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: <mailto:gentoo-dev@gentoo.org> List-Help: <mailto:gentoo-dev-help@gentoo.org> List-Unsubscribe: <mailto:gentoo-dev-unsubscribe@gentoo.org> List-Subscribe: <mailto:gentoo-dev-subscribe@gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 4173 invoked from network); 21 Jul 2004 03:10:46 +0000 Message-ID: <40FDDEB5.8020603@engr.orst.edu> Date: Tue, 20 Jul 2004 20:10:45 -0700 From: Michael Marineau <marineam@engr.orst.edu> User-Agent: Mozilla Thunderbird 0.7.1 (X11/20040702) X-Accept-Language: en-us, en MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org References: <20040720131405.GW18023@mail.lieber.org> <40FDCD20.6080302@scms.waikato.ac.nz> In-Reply-To: <40FDCD20.6080302@scms.waikato.ac.nz> X-Enigmail-Version: 0.84.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p7 (Debian GNU/Linux) at oregonstate.edu X-Spam-Status: No, hits=0.0 tagged_above=-999.0 required=5.0 tests= X-Spam-Level: Subject: Re: [gentoo-dev] Revisiting GLEP 19 X-Archives-Salt: d9ee311c-dda8-4a79-921f-e59a6f54967a X-Archives-Hash: 0e8174d2421fe1f8a4d9e92168deaa1d -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Barry Shaw wrote: | I guess what I'm describing isn't strictly an enterprise gentoo (which I | don't think the community has the resources to support), more of a | slowed down version of the main portage tree. In my experience | maintaining a couple of hundred of gentoo machines centrally, its the | rapid pace of change in the main tree that causes problems. We only | only upgrade packages for security reasons, but whenever we do this, we | are forced to upgrade a multitude of other packages because they've | dropped out of portage. If we only had to upgrade packages for security | and depreciation reasons it would make for a much more stable | environment for the end users (which is what we're after ultimately) and | ~ it would make maintenence more manageable. I like this idea. It fits better with the way Gentoo already runs, and will work nicely once the pending glsa/emerge integration is complete. Another thought on top of this is that it would make sense to throw out the idea of enterprise snapshots alltogether. Instead, on the local system never force a user to install a new version if their current version's ebuild is removed from portage. So basicly, use the ebuilds that are already cached as a portage overly. This also has a second benifit on the unstable side. If someone needs to install an unstable package but that ebuild is later dropped in favor of a newer unstable version currently on the next emerge sync; emerge -Up world; the unstable package will be uninstalled and replaced by the current stable version (unless the issue is first addressed before the update). This can be troublesom, especially if someone is to quick and didn't notice that the package is being downgraded. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFA/d61iP+LossGzjARAkrpAJ0bHE9JV56ttk6dL3FM1XVS6LoMcACePNbH gro06Mifc/j9csS6KMuzlBI= =0+81 -----END PGP SIGNATURE----- -- gentoo-dev@gentoo.org mailing list