1 |
On 21:04 Wed 25 Jan 2012, "Paweł Hajdan, Jr." wrote: |
2 |
> On 1/25/12 10:23 AM, Thomas Kahle wrote: |
3 |
> > I suggest that emerge could signal its various failures via return |
4 |
> > codes. That would be useful in automated archtesting: |
5 |
> > |
6 |
> > https://bugs.gentoo.org/show_bug.cgi?id=400705 |
7 |
> |
8 |
> My opinion is very similar to what Brian Harring said on that bug: some |
9 |
> Python API would be much better than still pretty vague return code |
10 |
> (what would you do with it?). |
11 |
|
12 |
My test setup (as you probably know) uses bash scripts (autogenerated by |
13 |
app-portage/tatt) that call emerge with various USE-flag combinations |
14 |
and then protocol failures to be looked at individually. Those scripts |
15 |
can easily react to return codes. Sure thing, once the portage API |
16 |
access is available, the entire test setup can be rewritten using it. I |
17 |
just don't see this happening anytime soon. Making the return codes |
18 |
more versatile should be quick and easy to implement. It's very KISS. |
19 |
|
20 |
> Some ideas: |
21 |
> |
22 |
> - I emerge a list of packages, some unstable dependencies are required; |
23 |
> allow me to get a list of those package atoms |
24 |
> |
25 |
> - same as above, but return list of USE flags adjustments required |
26 |
> |
27 |
> - package blocks |
28 |
> |
29 |
> - unsatisfied USE flag constraints |
30 |
> |
31 |
> ... and so on. I think it can start very simple and small, and be |
32 |
> extended as needed. |
33 |
|
34 |
I think those ideas are great and natural, but I'd still prefer to have |
35 |
something that is usable very soon instead of waiting for the portage |
36 |
API to be available (and documented). |
37 |
|
38 |
Cheers, |
39 |
Thomas |
40 |
|
41 |
|
42 |
|
43 |
-- |
44 |
Thomas Kahle |
45 |
http://dev.gentoo.org/~tomka/ |