Andy Dustman schrieb: [snipp] > Some sort of management tool is going to be needed on the gentoo.org > side of things to make all this possible. We already have GLSAs, so > ebuild that implements a GLSA fix should go into security. You cannot just take random ebuilds and stick them into an overlay. Ebuilds have dependencies on other ebuilds and the dependency tree changes with USE flags set. There are no backports. That is, a security upgrade is a new version with (possibly) new dependencies.
To generate a "security" tree you would need to pull from the tree: 1. the package "foo" that fixes the glsa 2. all packages package "foo" *requires* and is not in "baseline" 3. point 2 for all possible combinations of USE flags for package "foo". I'm not sure this is feasible. Any other > changes from the baseline release would go into updates. Actually, > there are a couple different scenarios: > > 1) baseline and updates: baseline is static data from initial release, > updates contains any changed files. > > 2) baseline, updates, and security: As #1, except builds with security > updates go into security. > > 3) baseline, testing, updates, security: As #2, except any > testing-only ebuilds go into testing. > > 4) Variation on : Keep the existing single tree with everything in > addition to having release-specific trees. regardless what "labels" you want. You need to provide a method (read: implementation ;) )to split the tree (thats what you're doing) so that you don't break dependencies. cheers Paul -- [email protected] mailing list
