Re: [gentoo-dev] Re: Versioning the tree

[Chris Gianelloni]

On Mon, 2006-11-27 at 16:18 +0100, Kevin F. Quinn wrote:
> One method could be to snapshot all package versions at the time that
> Release Engineering make a release, building a package.mask file out of
> it masking out all packages of higher revisions (i.e. having '>CPVR'
> entry for every package in the tree in stable, and 'CPVR' if no
> versions are stable).

It would be infinitely easier to create a tree just for this.

> Then, rather than back-port security fixes, this list would be updated
> with security-fixed version numbers, along with minimum required updates
> to dependent packages. The lists could be stored in the tree; for
> example as profiles/default-linux/x86/stable.mask.

This is essentially the idea that my release tree uses, except the tree
itself is completely stripped down to stable packages.  I have a script
which already does several things:

#1. grabs "best_visible" for stable on each arch
#2. repeat for each SLOT
#3. purge unnecessary files from FILESDIR
#4. strip to only "stable" profiles from profiles.desc
#5. purge unnecessary USE from use.local.desc and use.desc
#6. strip unused eclasses
#7. regenerate Manifest (via ebuild $foo digest)

I had also planned on it doing the following, but they haven't been
implemented just yet:

- strip all USE flags that aren't used from use.mask (per-profile)
- strip all packages that aren't available from package.mask
(per-profile)

What this gives us is a *much* smaller tree, as it only includes stable
packages/versions.

> Obviously maintaining that list is some work; predominantly watching
> the announcements from the security team and fixing up dependencies,
> and masking out new packages (for what that's worth).  It could be
> regenerated on some or all releases, or perhaps on a yearly basis.  It
> would also mean that versions listed there cannot be removed from the
> tree (until they're bumped in the list).

Well, the simpler approach was to simply copy over the newer, secure
ebuilds, and any required dependencies, into the release tree.  There'd
be no need to update mask files and such this way.  It would also be
generated with the releases, automatically.

> Some of that maintenance could be tool-assisted; in particular masking
> new packages and finding the minimum required bumps to support a
> package that was bumped for a security fix.
>
> People who want to use it could then just soft-link
> from /etc/portage/package.mask to that list.
>
> It's just a suggestion - I'm not prepared to do the work ;)  However it
> might be a simple but effective method to help people maintain secure
> but relatively stable systems, without having to upgrade umpteen
> packages a week.

Well, I am willing, and have been doing, some of the work.  The one
disadvantage to my design is it needs infra.  It needs it's own
repository and rsync.

Basically, it makes the system act a bit more like some other
development models.  We end up with the following:

rsync://rsync.gentoo.org/gentoo-portage (this is equivalent to -current)
rsync://rsync.gentoo.org/2007.0-release (this is the release tree)

Now, the release trees are non-moving.  The 2007.0-release tree is
*always* the 2007.0-release tree for as long as we decide to support it.
Likely, this support period would begin as a single release and get
extended as volunteers came around to support it.  New releases get
their own tree.

I also started writing a tool to "upgrade" the distribution.  The tool
reads pre and post scripts for the upgrade, and performs the necessary
steps.  Basically, a user can "dist-upgrade 2007.1" and the system
would:

- switch to the "2007.1" tree and "emerge --sync"
- perform all "pre" steps from 2007.1
- update world + revdep-rebuild + whatever else is necessary
- perform all "post" steps

With this, there would be a special "version" called "current" which
would put the user on the "gentoo-portage" tree, AKA the tree we all
know and love/loathe.  Release trees wouldn't have "arch" and "~arch" as
everything would be stable there.  Testing would be done in the main
tree.  This, in essence, gives us "testing", "release candidate" and
"stable" environments, with the release trees being stable, and the
current tree becoming test/release candidate.  Anything marked stable in
the current tree would be a candidate for stable in the next release
tree.

Users who want to use the current portage tree get what they want.
Users who want a more stable tree get what they want.  Basically,
everyone (hopefully) is happy, or at least as happy as we can feasibly
make them.

-- 
Chris Gianelloni
Release Engineering Strategic Lead
Alpha/AMD64/x86 Architecture Teams
Games Developer/Council Member/Foundation Trustee
Gentoo Foundation