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

[Caleb Cushing]

they could pull the more current ebuilds and put them in an overlay.
also correct me if I'm wrong isn't it possible only to sync certain
parts of the tree using excludes. maybe some additional functionality
saying only sync package X for updates.

On 11/28/06, James Potts <arek75@×××××.com> wrote:
> On 11/28/06, Chris Gianelloni <wolf31o2@g.o> wrote:
> > 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.
> >
>
> This looks good on the surface, Chris, but what happens in the case
> where somebody wants to use the Release tree, but also wants (or
> needs) one or more packages from the Live tree, and doesn't want to
> switch completely over to the live tree?  If I understand what you
> want to do correctly, the Release tree would include only stable
> packages.  Other packages wouldn't just be masked, they would be
> completely unavailable to anybody using that tree.
>
> I like the idea of having a stable p.mask much better, which says
> "profile" to me.  Any thoughts on a special profile just for releases?
>
> --Arek (James Potts)
> arek75@×××××.com
> --
> gentoo-dev@g.o mailing list
>
>
-- 
gentoo-dev@g.o mailing list