Am Mittwoch 16 August 2006 16:11 schrieb Paul Kölle: > 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?
Eh, no. In my opinion it is clear what I want to say, so I have nothing to add. > > 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. The ~arch ebuilds are not the point, the stable ebuilds which potentially be upgraded are the point. If you say that glsa-check does only update the package which is security relevant and tries not to update the dependencies then this is what I want. Regards Jan -- [email protected] mailing list
