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