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

[Ron O'Hara]

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@g.o mailing list