Hi, I was recently reading this post [1] about gentoo's future, it
mentioned a few items in relation to enterprise Gentoo, and that it
currently needs features that just aren't available yet.
One such example of a feature thats not available yet is GLEP 19: Gentoo
Stable Tree [2].
Now, I notice that it is over a year old since last edit, and that it is
still Draft, not Differed or Rejected.
So, I propose to change it in hopes of making it a feasible,
implementable idea.
The part of this GLEP that specifically is the issue, and making it
unable to be voted on, is the section concerning the exact details of
how/where the 'stable' tree would be located; currently this GLEP lists
a few ideas but settles on using KEYWORDS="stable". However, the point
was brought up (and noted inside of the GLEP) that in order for that new
keyword to work for independent archs, it would have to be
'stable:arch'. So, I am here to say 'No' to that idea. Specifically
because I believe it will make dev even greater then what it currently
is. Hence I propose that instead of a separate tree based on these
'stable:arch' keywords, the existing tree is used /with/ a new
keywording system: KEYWORDS="+arch" will denote these stable ebuilds.
Also, in order to prevent excess dev-work and to make a predictable
cycle, the following will also occur: prior to the release of the year's
.0 media (ex 2006.0) a script would be ran that add +arch for each arch
keyword (max one +arch per arch). Over the course of time, major bug
fixes and security updates would allow for items to be marked +arch
quickly, without necessarily waiting for the next media release.
When the .0 media is released, it would include the usual portage tree
in tar.bz2 which will serve as a static place for enterprise to install
Gentoo from. All security and Major bug fixes would be included in .1
and .2 releases, but the vast majority of the tree would remain the same
over the course of the year (enterprise's goals).
Also, a few items which can be considered for this stable tree:
- using a simple script it would be possible to make a copy of the tree
which only contains these +arch entries, this could be used to make
easier to manage tar balls of the stable tree for distribution to clients.
- the existing portage code would consider +arch as a subset of arch,
the reason both keywords will exist is to maintain compatibility with
older versions of portage which will not recognize this.
Anyways, I would personally like to see if this can stir some interest.
I would be willing to help test and help make this GLEP a reality,
however I can not implement this myself as I lack python skills, but I
do want to help the portage team, as much as I can, to make this happen,
as I have some great benefit from this added feature.
Also, I hope I covered everything, and if the response from the mailing
list is good I may consider revising the existing GLEP and prepare it
for submittal to the council in feburary, or march, depending on how
much revision the GLEP needs, and if my idea is better or worse then the
current solution proposed.
Thanks for taking the time to look at this, Please respond with personal
opinions (+ and -)
Andrew Muraco
Tuxp3
[1] http://article.gmane.org/gmane.linux.gentoo.devel/34870
[2] http://www.gentoo.org/proj/en/glep/glep-0019.html
--
gentoo-dev@gentoo.org mailing list
