Chris Gianelloni wrote: > It would be much better to simply use what we currently have, > though. Honestly, I was pursuing this with Infra a few months back, and > have since dropped it, due to time constraints. I plan on picking it > back up, as I said, so I don't know what is necessary at this point. > Makes sense.
>> > Now, the release trees are non-moving. The 2007.0-release tree is >> > *always* the 2007.0-release tree for as long as we decide to support >> > it. Likely, this support period would begin as a single release and get >> > extended as volunteers came around to support it. New releases get >> > their own tree. >> > >> Well count me in as a volunteer to help set this up and maintain an x86 >> release. I'm a pretty good coder if that helps. > > There wouldn't be an "x86 release" or anything. It would be the whole > thing. All or nothing. > I hear you- it's the tree that's being released. I guess x86 is the most common architecture anyway, so testers for it aren't gonna be hard to find. >> > Users who want to use the current portage tree get what they want. >> > Users who want a more stable tree get what they want. Basically, >> > everyone (hopefully) is happy, or at least as happy as we can feasibly >> > make them. >> > >> This all sounds great. Respect for the work you've already put in. > > Well, Andrew Gaffney really helped out, as he's been doing the python > work to utilize portage to get the proper information to strip the tree. > Since these scripts were originally written and subsequently abandoned, > they've needed a little work. Andrew and I are working on this now to > try to get everything back to working order. > Well can I take the opportunity to thank you both then? It's clearly something with interest, as you mentioned. >> From your post we need to add: >> > - strip all USE flags that aren't used from use.mask (per-profile) >> > - strip all packages that aren't available from package.mask >> > (per-profile) >> >> What language is the script implemented in? > [Andrew Gaffney wrote:] > The current script is actually 2 scripts: a python script that I wrote > that interfaces with the portage API and a bash script that wolf31o2 wrote > that takes the output from my script and does the cleanup. > > Last night, with the help of ferringb, I started working on a replacement > script that uses the pkgcore API. The portage-based script takes quite a > while to run, and gets it wrong if there are any p.mask'd stable packages > on any arch or other weird things. The pkgcore-based script actually uses > the profiles properly and runs over the entire tree with all the "stable" > profiles (according to profiles.desc) in 1m1.869s (on my box). I'll > probably end up combining the scripts and doing the cleanup in python to > make things easier. Excellent; pkgcore really sounds great- is there any possibility that it'll become the new portage? >> Wrt security updates, is it possible to tie into GLSAs so that we could >> automate updating packages that need it? By updating I mean adding the >> ebuilds and any dependencies (or dependants that might require updating.) > > What were you expecting that we would do? > Lol; exactly that. I guess I was asking how difficult it is to automate the process. Although Andrew wrote that he didn't think it was necessarily the best idea. Why is that? >> > No version changes on any packages, except those which are necessary >> > due to a security violation, or a vulnerable package's dependencies. >> > >> I could imagine a situation where a dependant package (ie one using the >> package updated) would also require an update. It'd be rare though, so I >> guess it wouldn't need automating. > > "or a vulnerable package's dependencies" > Sure, if the update meant the dependencies needed updating too. Again, that'd need automating, so we're talking about checking the tree in both directions (dependencies and dependants in my terms, sorry if I'm using the words wrongly.) > One thing that I am working on doing with agaffney is building more and > more automated systems for doing testing. We have our Release > Engineering build box doing weekly builds of all of the stages from > scratch for i686. I plan on doing the same for i586/no-nptl, to cover > that facet, as well as amd64. Currently, I am testing against the > dev/2007.0 profile, but plan on testing against dev/2007.0/desktop and > dev/2007.0/server in addition to the dev/2007.0 profile. > > I will also be adding a test suite on my Alpha and PPC machines at home. > Aside from this, I will be running catalyst tinderbox builds on at least > x86/amd64 for many packages that aren't included in the LiveCD/LiveDVD > sets. At some point, I'll likely be asking for suggestions on packages > to add to this testing. > This all sounds wicked. The more automation the better. -- gentoo-dev@gentoo.org mailing list
