From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5659 invoked by uid 1002); 17 Aug 2003 23:48:34 -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 1909 invoked from network); 17 Aug 2003 23:48:34 -0000 Message-ID: <3F400F68.3080806@sentuny.com.au> Date: Mon, 18 Aug 2003 09:27:36 +1000 From: Ron O'Hara User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4) Gecko/20030624 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stuart@gentoo.org Cc: gentoo-dev@gentoo.org References: <3F3FFCFF.2080804@sentuny.com.au> <200308172313.43267.stuart@gentoo.org> In-Reply-To: <200308172313.43267.stuart@gentoo.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] Large scale deployments - and portage X-Archives-Salt: d993eb71-cad9-4c91-a4b5-e901c41b6cbe X-Archives-Hash: 25953ac8415d6a71ee1c5724dacb1f6b Hi Stuart, >You might want to have a look at running your own (internal) rsync mirror for >your Gentoo boxes - and your own (internal) distfiles mirror too. This gives >you complete control over what ebuilds your many Gentoo machines will get, >and ensures that you can roll out software long after it has been removed >from Gentoo's portage (we delete 'old' files all the time, when we believe >they're obsolete, which really screws up consistency across a large >deployment. However, with your own internal mirror, you can keep these >ebuilds and their distfiles around long after Gentoo has dropped them!) > Having your own rsync mirror is only really like having a single extra 'tag'... although it does address the issue of ebuilds that disappear. (so does /usr/local/portage) The other deficiency with running your own rsyncmirror is just that it's effectively a private 'fork' - that pushes lots of the maintenance issues back into your own lap. A primary benefit of using any 'distro' is that a bigger team is keeping an eye on all the changes going on. With a commercially backed distro like RedHat you are hoping that they have the financial resources to keep on supporting that distro and creating RPMS to match the old releases. You also have a defined statement about how long a particular old release is supported. Personally, I prefer the open source community approach for real guarantees that support will continue -even if I need to do a little bit of it myself on behalf of the community - and this is a different issue from the idea of supporting 'tags' against the emerge sync. The community (collectively) has more resources than any individual or company. You are also right that removing 'old' files from portage is an issue... in fact probably a show stopper in some instances. Perhaps the solution is to look at it as if the portage tree is under CVS control. That would make the unstable "~arch" stuff associated with the HEAD of the tree. You would need a label to identify the equivelant of the 'stable' branch. Other labels would represent the 'tag's available for using with emerge sync. In this style of setup, old ebuilds are not 'deleted' - just removed from the stable and HEAD parts of the tree. IE. They still exists within the 'tag' that represents the historical development of gentoo. They are no longer maintained, but are still part of an 'old release' (or tag) (I'm really thinking of it more in terms of a Clearcase style version control file system where a user has a 'view' of the files at a particular point in time on a particular branch of development - maybe use http://www.gnu.org/directory/sysadmin/vc/cvsfs.html ???) The associated space and bandwidth issues for mirror sites can be addressed by only mirroring the HEAD and 'stable' parts - this is the same as the current level. It then becomes easy to implement a policy for support of 'back releases' - you could just choose something like - "gentoo maintains four years worth of tagged versions." Not only that, if any company wants to have a longer timeframe supported, then they only need to offer disk space and bandwidth support to achieve this - or THEN run their own rsync mirror. Since gentoo is a source level distro, many of the hassles that RedHat, Mandrake etc have making RPMS for old releases dont apply. I'm NOT implying developer support for 'old' ebuilds - but if package 'xzy' used to be available with Gentoo in Aug2002, it should still be available when you are building a system at that version level. This would also mean that if someone really must have it supported - then they can do it themselves and get it moved back into the main branch. If this 'tag' idea makes it attactive for companies to use Gentoo, then I would expect an explosion in the number of active (company paid) developers maintaining the ebuilds of little programs that the core team could not justify supporting. Another thing that running your own rsync mirror can never achieve is third party vendor certification. Having defined 'tags' would allow companies like Oracle to certify a particular version of Gentoo as being supported. Thats not currently possible. The very power and flexibility that Gentoo gives developers is also totally incompatible with the major software vendor QA techniques. Using a 'tag' would go a long way to overcoming this. It would become possible for people like SAP to certify their products as supported with specific 'make.conf' settings for a specific tag. Thats enough to make Gentoo fine for both the Quality Assured type large deployment and yet still retain brilliant upgrade and security patch capabilities. Cheers Ron > >Tbh, it's a hack, rather than a nice solid server/client enterprise-ready >Portage solution, but it's one that does work. > >Best regards, >Stu > > -- gentoo-dev@gentoo.org mailing list