From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23407 invoked by uid 1002); 18 Aug 2003 00:29:55 -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 32552 invoked from network); 18 Aug 2003 00:29:54 -0000 Date: Sun, 17 Aug 2003 17:22:07 -0700 From: Matt Thrailkill To: gentoo-dev@gentoo.org Message-Id: <20030817172207.54a6de08.xwred1@xwredwing.net> In-Reply-To: <3F400F68.3080806@sentuny.com.au> References: <3F3FFCFF.2080804@sentuny.com.au> <200308172313.43267.stuart@gentoo.org> <3F400F68.3080806@sentuny.com.au> X-Mailer: Sylpheed version 0.9.2 (GTK+ 1.2.10; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [gentoo-dev] Large scale deployments - and portage X-Archives-Salt: 5b167329-33d1-44e1-aebd-00644a3b0226 X-Archives-Hash: 9695b0a594832a86eb9c44ebd4f4d2f0 I've been using my own rsync mirror for my handful of Gentoo boxes, and for a long time I've been lusting after something like tagged branches of the Portage tree like how you have Woody or Slink or Sarge in Debian, or how you have -CURRENT, -STABLE, -RELENG_N_M in FreeBSD. This discussion has come up a few times on this list before, in short form. It sounds like the core Gentoo team is busier with other things, and the zeitgeist is that people like us would just use the GRP. I'd LOVE to start/work on some sort of project to maintain different Portage trees for people to rsync against. I think it could work out really well, it'd be a symbiotic relationship to the current Gentoo - the herd of Gentoo developers can continue advancing the distro, adding bleeding edge ebuilds to Portage, etc. Basically, advancing the Gentoo analogue of sid/-CURRENT. Then the other Portage Branches project can siphon off the ebuilds they want and apply their own pessimism to create stable branches, versioned releases of the tree and so on. Then people pick the branch they want to sync against, and use it. I wrote a short rant about it here: http://branched.modestolan.com On Mon, 18 Aug 2003 09:27:36 +1000 Ron O'Hara wrote: > 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 > > -- gentoo-dev@gentoo.org mailing list