Jan Meier wrote:
> Am Mittwoch 16 August 2006 15:12 schrieb Paul Kölle:
>> Jan Meier wrote:
>>> I would be willing to start such a stable tree, I am thinking of taking a
>>> current portage tree, delete all ~arch ebuilds and create an overlay.
>>> Every time a security announcement is fired up I will add the newer
>>> ebuild to the overlay, checking for any really needed depencies.
>> ~arch doesn't hurt, so the main difference to glsa-check+standard tree
>> would be old ebuilds not being deleted right? 
> 
> No, the advantage would be that new ebuilds would not come into the portage 
> tree. Only security relevant ebuilds, formerly which fix security holes, 
> would come into the tree (kernel, php, mysql, apache, etc. should not be 
> stopped from entering the portage tree).
Sorry, I don't get it. Why are you concerned about packages in the tree
you don't use? Is it about space savings?

> This has the advantage that there would be less packages to update when the 
> system has to be updated. And if there are security relevant updates there 
> would not be as much dependency updates as with the normal tree.
The depgraph of a bumped package does not depend on being bumped due to
a GLSA or not. If you only use glsa-check, you will get GLSA triggered
upgrades only and glsa-check will emerge the lowest safe version
possible. Keeping old versions around is sufficient to prevent unneeded
upgrades. If you want something like "emerge -u --stable world", well
then you would need a dedicated tree for --stable but thats way more
work than just deleting ~arch ebuilds you wouldn't use anyway.

> 
> Take a look here:
> http://www.gentoo.org/proj/en/glep/glep-0019.html
This glep talkes about a "stable tree" which conforms to some "higher"
QA standars than <arch> but I haven't seen much work here. Portage does
not support the "stable:<arch>" syntax and there is no sign gentoo devs
can handle those "higher QA" currently (see my comments on backporting
and missing seperate security patches upstream).

cheers
 Paul
-- 
[email protected] mailing list

Reply via email to