1 |
On 11/28/06, Chris Gianelloni <wolf31o2@g.o> wrote: |
2 |
> On Mon, 2006-11-27 at 16:18 +0100, Kevin F. Quinn wrote: |
3 |
> > One method could be to snapshot all package versions at the time that |
4 |
> > Release Engineering make a release, building a package.mask file out of |
5 |
> > it masking out all packages of higher revisions (i.e. having '>CPVR' |
6 |
> > entry for every package in the tree in stable, and 'CPVR' if no |
7 |
> > versions are stable). |
8 |
> |
9 |
> It would be infinitely easier to create a tree just for this. |
10 |
> |
11 |
> > Then, rather than back-port security fixes, this list would be updated |
12 |
> > with security-fixed version numbers, along with minimum required updates |
13 |
> > to dependent packages. The lists could be stored in the tree; for |
14 |
> > example as profiles/default-linux/x86/stable.mask. |
15 |
> |
16 |
> This is essentially the idea that my release tree uses, except the tree |
17 |
> itself is completely stripped down to stable packages. I have a script |
18 |
> which already does several things: |
19 |
> |
20 |
> #1. grabs "best_visible" for stable on each arch |
21 |
> #2. repeat for each SLOT |
22 |
> #3. purge unnecessary files from FILESDIR |
23 |
> #4. strip to only "stable" profiles from profiles.desc |
24 |
> #5. purge unnecessary USE from use.local.desc and use.desc |
25 |
> #6. strip unused eclasses |
26 |
> #7. regenerate Manifest (via ebuild $foo digest) |
27 |
> |
28 |
> I had also planned on it doing the following, but they haven't been |
29 |
> implemented just yet: |
30 |
> |
31 |
> - strip all USE flags that aren't used from use.mask (per-profile) |
32 |
> - strip all packages that aren't available from package.mask |
33 |
> (per-profile) |
34 |
> |
35 |
> What this gives us is a *much* smaller tree, as it only includes stable |
36 |
> packages/versions. |
37 |
> |
38 |
> > Obviously maintaining that list is some work; predominantly watching |
39 |
> > the announcements from the security team and fixing up dependencies, |
40 |
> > and masking out new packages (for what that's worth). It could be |
41 |
> > regenerated on some or all releases, or perhaps on a yearly basis. It |
42 |
> > would also mean that versions listed there cannot be removed from the |
43 |
> > tree (until they're bumped in the list). |
44 |
> |
45 |
> Well, the simpler approach was to simply copy over the newer, secure |
46 |
> ebuilds, and any required dependencies, into the release tree. There'd |
47 |
> be no need to update mask files and such this way. It would also be |
48 |
> generated with the releases, automatically. |
49 |
> |
50 |
> > Some of that maintenance could be tool-assisted; in particular masking |
51 |
> > new packages and finding the minimum required bumps to support a |
52 |
> > package that was bumped for a security fix. |
53 |
> > |
54 |
> > People who want to use it could then just soft-link |
55 |
> > from /etc/portage/package.mask to that list. |
56 |
> > |
57 |
> > It's just a suggestion - I'm not prepared to do the work ;) However it |
58 |
> > might be a simple but effective method to help people maintain secure |
59 |
> > but relatively stable systems, without having to upgrade umpteen |
60 |
> > packages a week. |
61 |
> |
62 |
> Well, I am willing, and have been doing, some of the work. The one |
63 |
> disadvantage to my design is it needs infra. It needs it's own |
64 |
> repository and rsync. |
65 |
> |
66 |
> Basically, it makes the system act a bit more like some other |
67 |
> development models. We end up with the following: |
68 |
> |
69 |
> rsync://rsync.gentoo.org/gentoo-portage (this is equivalent to -current) |
70 |
> rsync://rsync.gentoo.org/2007.0-release (this is the release tree) |
71 |
> |
72 |
> Now, the release trees are non-moving. The 2007.0-release tree is |
73 |
> *always* the 2007.0-release tree for as long as we decide to support it. |
74 |
> Likely, this support period would begin as a single release and get |
75 |
> extended as volunteers came around to support it. New releases get |
76 |
> their own tree. |
77 |
> |
78 |
> I also started writing a tool to "upgrade" the distribution. The tool |
79 |
> reads pre and post scripts for the upgrade, and performs the necessary |
80 |
> steps. Basically, a user can "dist-upgrade 2007.1" and the system |
81 |
> would: |
82 |
> |
83 |
> - switch to the "2007.1" tree and "emerge --sync" |
84 |
> - perform all "pre" steps from 2007.1 |
85 |
> - update world + revdep-rebuild + whatever else is necessary |
86 |
> - perform all "post" steps |
87 |
> |
88 |
> With this, there would be a special "version" called "current" which |
89 |
> would put the user on the "gentoo-portage" tree, AKA the tree we all |
90 |
> know and love/loathe. Release trees wouldn't have "arch" and "~arch" as |
91 |
> everything would be stable there. Testing would be done in the main |
92 |
> tree. This, in essence, gives us "testing", "release candidate" and |
93 |
> "stable" environments, with the release trees being stable, and the |
94 |
> current tree becoming test/release candidate. Anything marked stable in |
95 |
> the current tree would be a candidate for stable in the next release |
96 |
> tree. |
97 |
> |
98 |
> Users who want to use the current portage tree get what they want. |
99 |
> Users who want a more stable tree get what they want. Basically, |
100 |
> everyone (hopefully) is happy, or at least as happy as we can feasibly |
101 |
> make them. |
102 |
> |
103 |
|
104 |
This looks good on the surface, Chris, but what happens in the case |
105 |
where somebody wants to use the Release tree, but also wants (or |
106 |
needs) one or more packages from the Live tree, and doesn't want to |
107 |
switch completely over to the live tree? If I understand what you |
108 |
want to do correctly, the Release tree would include only stable |
109 |
packages. Other packages wouldn't just be masked, they would be |
110 |
completely unavailable to anybody using that tree. |
111 |
|
112 |
I like the idea of having a stable p.mask much better, which says |
113 |
"profile" to me. Any thoughts on a special profile just for releases? |
114 |
|
115 |
--Arek (James Potts) |
116 |
arek75@×××××.com |
117 |
-- |
118 |
gentoo-dev@g.o mailing list |