Re: [gentoo-dev] Revisiting GLEP 19

[Olivier Crete <tester@gentoo.org>]

Hi,

The main problem with the profiles approach is that need to keep all of
the "old" ebuilds for previous profiles in the tree, unnecessarily
bloating the tree and then we have the risk that package maintainers
will remove the stable packages after a while by mistake..

My favorite solution is the portage snapshot + overlay solution. Where
the gentoo-stable project makes a snapshot (like we already do on every
livecd), it could even be the same snapshot. And then maintain (in a new
tree) an overlay with only security fixes. This tree could then be
rsynced with gensync (or with a modified portage). 


Olivier

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

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer


--
gentoo-dev@gentoo.org mailing list