Gentoo Archives: gentoo-dev

From: Kurt Lieber <klieber@g.o>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] GLEP 19, reloaded (again)
Date: Sun, 08 Aug 2004 18:49:42
Message-Id: 20040808185144.GB29077@mail.lieber.org
1 OK, as msot of the other folks who attended LWE will attest, a stable
2 portage tree was the number one most-requested/discussed feature at the
3 booth. So, here's a stab at summarizing the other flame^Wthread and
4 suggesting some next steps...
5
6 First off, some folks tried to bolt on some features to the GLEP 19.
7 Things such as XML-based ChangeLogs might be nice, but they're outside the
8 scope of this GLEP. So, I'm ignoring them for purposes of this discussion.
9
10 Second, there was some question about how often the tree would be updated.
11 The GLEP doesn't really specify this, but I think once a year is a
12 reasonable timeframe.
13
14 Third, many folks want long-term support of these releases. I *don't*
15 think this is viable and am not willing to personally sponsor this. A core
16 component of this GLEP is that we will *not* be backporting security fixes.
17 (at least not as a rule) We will be relying on the versions that the
18 original authors provide except in very unusual circumstances. The reason
19 for this is simple -- we don't have the resources to guarantee that we can
20 backport things (and, more importantly, guarantee that they'll work right
21 once backported) Suppporting a profile for four or more years almost
22 guarantees you'll be doing a lot of backporting. I don't plan to
23 incorporate long-term support as part of this GLEP. That might, however,
24 be an excellent opportunity for commercial companies with greater finanial
25 resources than us.
26
27 Fourth, the GLEP currently recommends use of a 'stable' keyword. A
28 number of folks have suggested using a custom profile instead. This is
29 less intrusive and doesn't require any changes to portage to make it work.
30 It's also easier to maintain since everything is in one file. The main
31 problem here is that all packages need to be explicitly listed in this file
32 in order to be of any use. If we can get enough developer buy-in and maybe
33 even add some repoman checks, this might be easier to manage...
34
35 Finally, the current GLEP doesn't really address how to ensure a minimum
36 life for all ebuilds in the tree. I'm open to suggestions on this, but the
37 best idea I've heard so far is using a separate rsync module and removing
38 the --delete option from the command used to populate it.
39
40 So, at this point, I'm suggesting three changes to the GLEP:
41
42 1) specify annual updates for the stable tree
43 2) replacing the stable keywording stuff with stable profiling stuff
44 3) adding a separate rsync module for the stable portage tree (or one for
45 each release of the stable portage tree)
46
47 With that, comments/suggestions are welcome. Please keep in mind that this
48 is a very focused GLEP designed to provide a stable tree and predictable
49 expiration of ebuilds to our users. It is not intended to propose other
50 far-reaching changes to Gentoo Linux.
51
52 --kurt

Replies

Subject Author
Re: [gentoo-dev] GLEP 19, reloaded (again) Dylan Carlson <absinthe@g.o>
Re: [gentoo-dev] GLEP 19, reloaded (again) Greg KH <gregkh@g.o>
Re: [gentoo-dev] GLEP 19, reloaded (again) Barry Shaw <baz@×××××××××××××××.nz>
Re: [gentoo-dev] GLEP 19, reloaded (again) Olivier Crete <tester@g.o>