Re: [gentoo-dev] GLEP 19, reloaded (again)

[Chris Gianelloni]

On Tue, 2004-08-10 at 14:05, Spider wrote:
> begin  quote
> On Tue, 10 Aug 2004 00:01:07 +0000
> Kurt Lieber <klieber@g.o> wrote:
>
> > One think that I think *everyone* agrees on is that any stable tree
> > needs to be regularly updated with security fixes.  With this in mind,
> > I'm concerned with trying to maintain multiple separate SYNC modules.
> > We'd have to upgrade each one with every GLSA, thus doubling or
> > tripling the amount of CVS work needed each time.
>
> Once again, coming from an ISV standpoint where we would have loved to
> use Gentoo (or, I would, some of the people wouldn't care, and one or
> two i'd have to beat to make them bend to my will, but whatever ;)
>
> We had to scrap both Gentoo -and- Debian stable trees. Why?  Because
> both update the -main- repository when releasing security fixes/
> bugfixes. Neither have a stable tree thats archived once and never
> changes.

I have no problem with that at all, and this is really more what I would
like to see.  The only reason I was mentioning using ~arch as a method
for security updates was to quell the people asking about security
updates.

> If you have to actively change a tree (modifications directly into the
> "frozen" tree) which is the case in many environmens, you get stuck with
> this problem. if upstream ever changes their tree, work is lost. You can
> separate local trees and so on, however, once again work is lost when
> internal revisions have superceeded the ones in the tree. (fex, local
> changes to sshd to patch ther initscripts and default config files
> before rollout, which ups the revision of openssh a few times, and then
> there is a backported securityfix?  It won't get merged. )
>
> this is why I'd like to push, once more, for separated "stable" (frozen
> snapshot basically) and "updates"  pushed in a separate repo. If we
> want others to use this in enterprise, we have to make it easy for them.
>   :-)

To accomplish this would require a change to portage, but I think it
could be done with minimal work.  Allow me to ramble... *grin*

We add something along the lines of a PORTAGE_TREE variable, that can be
set to either the release version, or to "current".  So you would have
for 2005.0 something like:

PORTAGE_TREE="2005.0"

in make.conf (actually, in make.profile/make.defaults).  When this is
set to something non-"current", then portage will rsync *only* the
2005.0 directory in the "gentoo-updates" module, which goes to an
updates directory under /usr/portage, which is just an overlay which is
added due to being non-"current".  The rest of the tree is *never*
synched when an emerge sync is done.  When PORTAGE_TREE="current", the
overlay doesn't exist, and the tree is synched as normal.

Now, this gives us a non-moving, completely frozen tree for
installations/QA/whatever and also gives us a mechanism for updates.  It
requires a little bit more work from the portage developers (whom I am
sure are busy enough), but then takes up minimal space on the mirrors
and requires the addition of only one rsync module.  It also keeps the
mirrors from having to process rsync over the entire frozen portion of
the tree.

-- 
Chris Gianelloni
Release Engineering QA Manager/Games Developer
Gentoo Linux

Is your power animal a penguin?