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
signature.asc
Description: This is a digitally signed message part
