Hi Rich,
Sorry about the delay getting back to you .. somewhat flatout here ...
The operational suport/production environment issues certainly haven't gone away for me - and given that we (apparently) have just won our first huge sale of product (2400 customer sites - not that many servers, but 79,000 people would be affected by outages) ... its about to get very, very real - not just a future concern of mine.
On the good side, it means that somewhere in the next two or three months, I expect to have some budget I can direct towards building a solution. AND I have the tentative support of corporate management to provide that support to the Gentoo community in addition to our own customer base.
I'm thinking along the lines of creating a Portage site which 'never' deletes ebuilds - though the tar files are a different issue.
With an accumulating set of ebuilds, it should be reasonable to create a 'snapshot' of any particular build of a system ... into /etc/portage/package.mask
So for a particular 'production' system image, I can create a system, then record it's actual package set in /etc/portage/package.mask.
This 'snapshot' is effectively the same as other distributions use for 'release' .. and I can adjust it later to provide selective package updates (for security issues). After the upgrade process and seeing how it will affect production systems, is done by testing in a QA process.
The same use of predictable change against known system sets, (after checking in a QA process) can be used for migration from one 'release' to the next. This is critical for large scale, long duration deployments.. and the product I'm involved in is expected to have at least a 20 year life span... and more likely 30-50 years. Really weird for an IT product.
The nice part of this approach is that anyone can use this approach to create their own 'release' for stable use in their own production environment - quite independently of my snapshots and QA approach.
All this relies on having a 'portage' repository with a much longer memory than the one currently managed by the Gentoo community. So thats what I'm planning for the near future.
Last time I looked, the --delete option in the 'emerge sync' is hard coded, rather than controlled by an option in /etc/make.conf .... pity.
I'm interested in any thoughts you have other things that might help this 'production' extension to using Gentoo
Regards Ron O'Hara
Rich J wrote:
Hi Ron,
I've just read your post to linux.gentoo.devel dated November 10, 2003 regarding the maintenance of older ebuilds for production systems.
As you've already guessed, I ran into the exact situation with open-ssl. Judging by the followup posts, I don't think the Gentoo developers fully
grasped why old ebuilds are the best solution for us.
I fully agree with your post and your solution -- almost. What we've done at work is to have a single server rsync with Gentoo's Portage servers. All other local boxes then sync with it -- kinda like how NTP synching is typically done with the concept of "stratum" levels. Maybe you would be able to implement something similar to help your situation?
For home, I'd like to find all the old ebuilds. I have neither the time nor the ability to troubleshoot the chaos resulting from an emerge world on my server every week.
Again, if you have found a solution, I'd be grateful to hear from you. My
alternative is to dump Gentoo, which I'm *really* trying hard not to. Between this and Gentoo's fixation with filling /var with things for which
it was never intended, I'm losing my faith...
Thanks! Rich Jesse [EMAIL PROTECTED]
-- [email protected] mailing list
