1 |
Chris Gianelloni wrote: |
2 |
|
3 |
> It would be much better to simply use what we currently have, |
4 |
> though. Honestly, I was pursuing this with Infra a few months back, and |
5 |
> have since dropped it, due to time constraints. I plan on picking it |
6 |
> back up, as I said, so I don't know what is necessary at this point. |
7 |
> |
8 |
Makes sense. |
9 |
|
10 |
>> > Now, the release trees are non-moving. The 2007.0-release tree is |
11 |
>> > *always* the 2007.0-release tree for as long as we decide to support |
12 |
>> > it. Likely, this support period would begin as a single release and get |
13 |
>> > extended as volunteers came around to support it. New releases get |
14 |
>> > their own tree. |
15 |
>> > |
16 |
>> Well count me in as a volunteer to help set this up and maintain an x86 |
17 |
>> release. I'm a pretty good coder if that helps. |
18 |
> |
19 |
> There wouldn't be an "x86 release" or anything. It would be the whole |
20 |
> thing. All or nothing. |
21 |
> |
22 |
I hear you- it's the tree that's being released. I guess x86 is the most |
23 |
common architecture anyway, so testers for it aren't gonna be hard to find. |
24 |
|
25 |
>> > Users who want to use the current portage tree get what they want. |
26 |
>> > Users who want a more stable tree get what they want. Basically, |
27 |
>> > everyone (hopefully) is happy, or at least as happy as we can feasibly |
28 |
>> > make them. |
29 |
>> > |
30 |
>> This all sounds great. Respect for the work you've already put in. |
31 |
> |
32 |
> Well, Andrew Gaffney really helped out, as he's been doing the python |
33 |
> work to utilize portage to get the proper information to strip the tree. |
34 |
> Since these scripts were originally written and subsequently abandoned, |
35 |
> they've needed a little work. Andrew and I are working on this now to |
36 |
> try to get everything back to working order. |
37 |
> |
38 |
Well can I take the opportunity to thank you both then? It's clearly |
39 |
something with interest, as you mentioned. |
40 |
|
41 |
>> From your post we need to add: |
42 |
>> > - strip all USE flags that aren't used from use.mask (per-profile) |
43 |
>> > - strip all packages that aren't available from package.mask |
44 |
>> > (per-profile) |
45 |
>> |
46 |
>> What language is the script implemented in? |
47 |
> |
48 |
[Andrew Gaffney wrote:] |
49 |
> The current script is actually 2 scripts: a python script that I wrote |
50 |
> that interfaces with the portage API and a bash script that wolf31o2 wrote |
51 |
> that takes the output from my script and does the cleanup. |
52 |
> |
53 |
> Last night, with the help of ferringb, I started working on a replacement |
54 |
> script that uses the pkgcore API. The portage-based script takes quite a |
55 |
> while to run, and gets it wrong if there are any p.mask'd stable packages |
56 |
> on any arch or other weird things. The pkgcore-based script actually uses |
57 |
> the profiles properly and runs over the entire tree with all the "stable" |
58 |
> profiles (according to profiles.desc) in 1m1.869s (on my box). I'll |
59 |
> probably end up combining the scripts and doing the cleanup in python to |
60 |
> make things easier. |
61 |
Excellent; pkgcore really sounds great- is there any possibility that it'll |
62 |
become the new portage? |
63 |
|
64 |
>> Wrt security updates, is it possible to tie into GLSAs so that we could |
65 |
>> automate updating packages that need it? By updating I mean adding the |
66 |
>> ebuilds and any dependencies (or dependants that might require updating.) |
67 |
> |
68 |
> What were you expecting that we would do? |
69 |
> |
70 |
Lol; exactly that. I guess I was asking how difficult it is to automate the |
71 |
process. |
72 |
|
73 |
Although Andrew wrote that he didn't think it was necessarily the best idea. |
74 |
Why is that? |
75 |
|
76 |
>> > No version changes on any packages, except those which are necessary |
77 |
>> > due to a security violation, or a vulnerable package's dependencies. |
78 |
>> > |
79 |
>> I could imagine a situation where a dependant package (ie one using the |
80 |
>> package updated) would also require an update. It'd be rare though, so I |
81 |
>> guess it wouldn't need automating. |
82 |
> |
83 |
> "or a vulnerable package's dependencies" |
84 |
> |
85 |
Sure, if the update meant the dependencies needed updating too. Again, |
86 |
that'd need automating, so we're talking about checking the tree in both |
87 |
directions (dependencies and dependants in my terms, sorry if I'm using the |
88 |
words wrongly.) |
89 |
|
90 |
> One thing that I am working on doing with agaffney is building more and |
91 |
> more automated systems for doing testing. We have our Release |
92 |
> Engineering build box doing weekly builds of all of the stages from |
93 |
> scratch for i686. I plan on doing the same for i586/no-nptl, to cover |
94 |
> that facet, as well as amd64. Currently, I am testing against the |
95 |
> dev/2007.0 profile, but plan on testing against dev/2007.0/desktop and |
96 |
> dev/2007.0/server in addition to the dev/2007.0 profile. |
97 |
> |
98 |
> I will also be adding a test suite on my Alpha and PPC machines at home. |
99 |
> Aside from this, I will be running catalyst tinderbox builds on at least |
100 |
> x86/amd64 for many packages that aren't included in the LiveCD/LiveDVD |
101 |
> sets. At some point, I'll likely be asking for suggestions on packages |
102 |
> to add to this testing. |
103 |
> |
104 |
This all sounds wicked. The more automation the better. |
105 |
|
106 |
-- |
107 |
gentoo-dev@g.o mailing list |