1 |
Hi, |
2 |
|
3 |
The main problem with the profiles approach is that need to keep all of |
4 |
the "old" ebuilds for previous profiles in the tree, unnecessarily |
5 |
bloating the tree and then we have the risk that package maintainers |
6 |
will remove the stable packages after a while by mistake.. |
7 |
|
8 |
My favorite solution is the portage snapshot + overlay solution. Where |
9 |
the gentoo-stable project makes a snapshot (like we already do on every |
10 |
livecd), it could even be the same snapshot. And then maintain (in a new |
11 |
tree) an overlay with only security fixes. This tree could then be |
12 |
rsynced with gensync (or with a modified portage). |
13 |
|
14 |
|
15 |
Olivier |
16 |
|
17 |
On Tue, 2004-07-20 at 16:43 -0400, Dylan Carlson wrote: |
18 |
> On Tuesday 20 July 2004 9:14 am, Kurt Lieber wrote: |
19 |
> > A while back, I wrote GLEP 19[1] based on some of the needs of the |
20 |
> > gentoo-server project. For various reasons, the GLEP was tabled at the |
21 |
> > time and never went anywhere. A number of folks have expressed an |
22 |
> > interest in revitalizing this GLEP, so I'd like to start a new |
23 |
> > discussion about implementing it. There was a couple of previous |
24 |
> > threads on this GLEP back when it was first introduced that I'll |
25 |
> > include[2] for your reference. |
26 |
> |
27 |
> My thoughts on this are: |
28 |
> |
29 |
> 1/ Many Gentoo users want the ability to update packages for fixes only |
30 |
> (and not just for servers) |
31 |
> 2/ Maintaining separate trees in CVS is probably asking too much of our |
32 |
> current roster, plus requires adding infrastructure and getting everyone |
33 |
> to mirror the new tree(s) |
34 |
> 3/ Users already have a good understanding of what profiles are. This is |
35 |
> useful. |
36 |
> 4/ Creating separate CVS trees while also using profiles seems superfluous. |
37 |
> |
38 |
> Therefore I believe another possible solution is to change the way we use |
39 |
> profiles (both in practice and in QA policy): |
40 |
> |
41 |
> Implications: |
42 |
> |
43 |
> 1/ archs will need to have a regular, predictable release schedule, |
44 |
> probably at least every six months. |
45 |
> 2/ profiles will list specific package versions whenever possible. e.g.: |
46 |
> =sys-libs/glibc-2.3.2 |
47 |
> 3/ we will need to prepare a list of packages which should not change |
48 |
> unless the user switches profiles. those packages (e.g., toolchain) in |
49 |
> the current, and older profiles do not get updated except for fixes. |
50 |
> 4/ we will need to have a policy about how long we'll support a profile, |
51 |
> and a procedure for end-of-lifing profiles. (probably don't want to |
52 |
> support a single profile for more than 2 years) |
53 |
> 5/ we will need to have documentation for users who are upgrading from one |
54 |
> profile to another (upgrade warnings, instructions and considerations) |
55 |
> 6/ repoman will need to be enhanced to check the profiles before removing |
56 |
> any ebuilds from the tree that might be needed. specific versions pinned |
57 |
> in profiles need to stay until the profile is changed. |
58 |
> |
59 |
> Potential problems: |
60 |
> |
61 |
> 1/ Makes KEYWORDS redundant |
62 |
> 2/ Unstable (unreleased) profiles will probably, often run into conflicts |
63 |
> during commit |
64 |
> |
65 |
> I probably missed some things, but it's a start. |
66 |
> |
67 |
> Cheers, |
68 |
> Dylan Carlson [absinthe@g.o] |
69 |
> Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x708E165F |
70 |
> |
71 |
> -- |
72 |
> gentoo-dev@g.o mailing list |
73 |
> |
74 |
|
75 |
-- |
76 |
Olivier CrĂȘte |
77 |
tester@g.o |
78 |
Gentoo Developer |
79 |
|
80 |
|
81 |
-- |
82 |
gentoo-dev@g.o mailing list |