Gentoo Archives: gentoo-dev

From: Chris Gianelloni <wolf31o2@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Gentoo "Stable" Portage/Releases
Date: Fri, 06 Jan 2006 19:24:04
1 First off, let me just say that this was just an idea I'd cooked up a
2 while back, so I am sure there's lots of holes in it for you guys to rip
3 apart. Anyway, without further ado...
5 The proposal is quite simple insofar as it requires no changes to
6 portage, whatsoever (though there are possibilities to make extensions
7 to portage). It introduces no new KEYWORDS and adds no load on the
8 current ebuild developers, other than those that wish to work on the
9 stable tree.
11 Allow me to explain.
13 First, there is the creation of the "release" tree. This tree is tied
14 to a specific release of Gentoo Linux. The tree is based on the release
15 snapshot used to build the release. The tree consists of the highest
16 version stable ebuild per slot and architecture for each package. This
17 means if there is no stable version of, say, vmware-player, then the
18 entire package is omitted. For things like GTK+, there would be at
19 least 2 versions in the tree, since there are 2 slots and both are
20 stable on at least one architecture. By only limiting the tree in this
21 manner, it can be built entirely by a script and require no manual
22 interactions to repair dependencies, etc.
24 So let's imagine that 2006.0 is rolling around. The 2006.0 snapshot is
25 frozen, and the release-building begins. This snapshot tarball is run
26 through our "stable" script, and a new gentoo-2006.0 CVS module is
27 created. A corresponding rsync module is created for this tree.
29 To facilitate "enterprise" usage, we break up the releases into a
30 "desktop" and "server" set. This means the current
31 "default-linux/$arch/2006.0" profile would be
32 "default-linux/$arch/2006.0/desktop" with a
33 "default-linux/$arch/2006.0/server" profile, also. The stages would be
34 built against the "default-linux/$arch/2006.0" profile, which would have
35 any USE, etc. that are common between desktop and server. During
36 installation, the user can choose to use either the desktop or server
37 profiles, or stay with the more "generic" 2006.0 profile (good for
38 developers, etc. that might need components of both, or want a more
39 minimal default set of USE flags). The desktop and server profiles will
40 have a defined set of default USE flags that will benefit the most
41 people, similar to how the current profiles are designed to be "desktop"
42 profiles, to benefit the most people.
44 The release media has SYNC set to this rsync module. What we would have
45 is SYNC="rsync://" in make.conf for this
46 release. Security updates would be applied to gentoo-2006.0, so "emerge
47 --sync" still allows for getting package updates, as we currently do. A
48 user can upgrade to 2006.1 by simply changing the SYNC setting and
49 updating their profile. A simple tool could be created for this, or
50 portage could be extended to allow for it (emerge --distupgrade 2006.1).
52 The current "gentoo-x86" CVS module would be the equivalent to Slackware
53 or FreeBSD's -current tree. Users that wish to participate in Gentoo
54 development, either via actual patches or simply by assisting in testing
55 new packages and filing bug reports, can use this tree with no
56 difference from how they operate now. This would also allow us to get
57 wider testing on the release profiles before the actual release is made.
59 Of course, a team would need to be created to work on the gentoo-$relver
60 trees. However, the trees would already exist with minimal effort on
61 anyone's part, allowing for an easier transition. In the end, this
62 would be only marginally more work for Release Engineering, so I don't
63 see much argument from my project, and minimal to no extra work for any
64 ebuild developers working on gentoo-x86 that do not also volunteer to
65 work on gentoo-$relver. Patches from gentoo-$relver would be
66 "upstreamed" into the gentoo-x86 tree, if they did not originate on
67 gentoo-x86, so the next gentoo-$relver tree would be already fixed.
69 Remember that the release trees would only be security fixes. No other
70 package updates should be happening. This would allow for companies to
71 actually certify their software against "Gentoo 2006.0", for example.
73 Even with no updates going into this tree, as would be the case when it
74 is originally implemented, we would still have a stable, unchanging
75 platform for external parties to test and verify against. They would
76 never be caught unaware with an apache upgrade or a gcc upgrade. They
77 would upgrade to new releases when *they* choose, giving them a stable
78 platform to build their Gentoo systems against. This concept also
79 allows for us to take "baby steps" in getting to a fully-supported set
80 of packages with back-ported security fixes. Because of this, I have
81 specifically omitted any retention or support periods, since I think
82 some kind of consensus would need to be reached on that, and I would
83 prefer that those particular details not cloud this proposal.
85 Speaking hypothetically, it would even be possible to create a separate
86 corporate entity that pays developers to work on gentoo-$relver trees by
87 back-porting patches and providing support to customers. Support and
88 patches could be maintained on any given tree for any length of time
89 decided. Yes, it could be possible for Gentoo to sell support.
91 I'm sure I'm missing a lot and this will be discussed to death, but this
92 is also the kind of thing that we definitely want to do right if we do
93 it, so feel free to punch holes all in this proposal (and I know you
94 will... :P).
96 --
97 Chris Gianelloni
98 Release Engineering - Strategic Lead
99 x86 Architecture Team
100 Games - Developer
101 Gentoo Linux


File name MIME type
signature.asc application/pgp-signature


Subject Author
[gentoo-dev] Re: Gentoo "Stable" Portage/Releases Duncan <1i5t5.duncan@×××.net>
Re: [gentoo-dev] Gentoo "Stable" Portage/Releases Andrew Muraco <tuxp3@×××××××××.com>