On Fri, Jan 27, 2012 at 1:33 AM, Thomas Kahle <[email protected]> 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 [email protected] 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/
