Re: [gentoo-dev] Large scale deployments - and portage

[Matt Thrailkill <xwred1@xwredwing.net>]

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 <rono@sentuny.com.au> 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