Hi,

I suggest that emerge could signal its various failures via return
codes. That would be useful in automated archtesting:

https://bugs.gentoo.org/show_bug.cgi?id=400705

Cheers,
Thomas


--
Thomas Kahle
http://dev.gentoo.org/~tomka/

On 1/25/12 10:23 AM, Thomas Kahle wrote:
> I suggest that emerge could signal its various failures via return
> codes. That would be useful in automated archtesting:
>
> https://bugs.gentoo.org/show_bug.cgi?id=400705

My opinion is very similar to what Brian Harring said on that bug: some
Python API would be much better than still pretty vague return code
(what would you do with it?).

Some ideas:

- I emerge a list of packages, some unstable dependencies are required;
allow me to get a list of those package atoms

- same as above, but return list of USE flags adjustments required

- package blocks

- unsatisfied USE flag constraints

... and so on. I think it can start very simple and small, and be
extended as needed.

On 21:04 Wed 25 Jan 2012, "Paweł Hajdan, Jr." wrote:
> On 1/25/12 10:23 AM, Thomas Kahle wrote:
> > I suggest that emerge could signal its various failures via return
> > codes. That would be useful in automated archtesting:
> >
> > https://bugs.gentoo.org/show_bug.cgi?id=400705
>
> My opinion is very similar to what Brian Harring said on that bug: some
> Python API would be much better than still pretty vague return code
> (what would you do with it?).

My test setup (as you probably know) uses bash scripts (autogenerated by
app-portage/tatt) that call emerge with various USE-flag combinations
and then protocol failures to be looked at individually. Those scripts
can easily react to return codes. Sure thing, once the portage API
access is available, the entire test setup can be rewritten using it. I
just don't see this happening anytime soon. Making the return codes
more versatile should be quick and easy to implement. It's very KISS.

> Some ideas:
>
> - I emerge a list of packages, some unstable dependencies are required;
> allow me to get a list of those package atoms
>
> - same as above, but return list of USE flags adjustments required
>
> - package blocks
>
> - unsatisfied USE flag constraints
>
> ... and so on. I think it can start very simple and small, and be
> extended as needed.

I think those ideas are great and natural, but I'd still prefer to have
something that is usable very soon instead of waiting for the portage
API to be available (and documented).

Cheers,
Thomas



--
Thomas Kahle
http://dev.gentoo.org/~tomka/

On Fri, Jan 27, 2012 at 1:33 AM, Thomas Kahle <tomka@gentoo.org> wrote:
> On 21:04 Wed 25 Jan 2012, "Paweł Hajdan, Jr." wrote:
>> On 1/25/12 10:23 AM, Thomas Kahle wrote:
>> > I suggest that emerge could signal its various failures via return
>> > codes. Â*That would be useful in automated archtesting:
>> >
>> > https://bugs.gentoo.org/show_bug.cgi?id=400705
>>
>> My opinion is very similar to what Brian Harring said on that bug: some
>> Python API would be much better than still pretty vague return code
>> (what would you do with it?).
>
> My test setup (as you probably know) uses bash scripts (autogenerated by
> app-portage/tatt) that call emerge with various USE-flag combinations
> and then protocol failures to be looked at individually. Â*Those scripts
> can easily react to return codes. Â*Sure thing, once the portage API
> access is available, the entire test setup can be rewritten using it. Â*I
> just don't see this happening anytime soon. Â*Making the return codes
> more versatile should be quick and easy to implement. Â*It's very KISS.

I agree, but we have gentoo-portage-dev@gentoo.org for this sort of thing?

-A

>
>> Some ideas:
>>
>> - I emerge a list of packages, some unstable dependencies are required;
>> allow me to get a list of those package atoms
>>
>> - same as above, but return list of USE flags adjustments required
>>
>> - package blocks
>>
>> - unsatisfied USE flag constraints
>>
>> ... and so on. I think it can start very simple and small, and be
>> extended as needed.
>
> I think those ideas are great and natural, but I'd still prefer to have
> something that is usable very soon instead of waiting for the portage
> API to be available (and documented).
>
> Cheers,
> Thomas
>
>
>
> --
> Thomas Kahle
> http://dev.gentoo.org/~tomka/