FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 01-25-2012, 08:23 AM
Thomas Kahle
 
Default RFC: More versatile return codes for emerge

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/
 
Old 01-25-2012, 07:04 PM
"Paweł Hajdan, Jr."
 
Default RFC: More versatile return codes for emerge

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.
 
Old 01-27-2012, 08:33 AM
Thomas Kahle
 
Default RFC: More versatile return codes for emerge

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/
 
Old 01-27-2012, 04:11 PM
Alec Warner
 
Default RFC: More versatile return codes for emerge

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/
 

Thread Tools




All times are GMT. The time now is 01:06 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org