For archtesting and possibly other purposes it would be useful if emerge could signal its various failures via return codes. Currently there are only two: 1 (failed) 128 + signal (signal received) I can think of the following - ebuild died - unsatisfied USE deps - unsatisfied keywords - ciruclar dependencies - pre-merge checks failed Reproducible: Always
Strikes me some of the stuff you're asking for is better resolved via api access...
(In reply to comment #1) > Strikes me some of the stuff you're asking for is better resolved via api > access... What stuff are you referring to? My test setup uses bash scripts that call emerge with various USE-flag combinations and then protocol failures. Those scripts could more 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.
(In reply to comment #2) > (In reply to comment #1) > > Strikes me some of the stuff you're asking for is better resolved via api > > access... > > What stuff are you referring to? My test setup uses bash scripts that call > emerge with various USE-flag combinations and then protocol failures. Which is a crappy way to be doing it, forced because zac hasn't gotten around to merging the api branch... > Those > scripts could more 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. Once those error codes are there, one can't just go rip them out when the public api branch is merged. There's a maintenance burden you're ignoring there. Regardless, it's a better use of time integrating the API crap in rather than adding yet another hacky attempt to work around the lack of it...
(In reply to comment #3) > (In reply to comment #2) > > (In reply to comment #1) > > > Strikes me some of the stuff you're asking for is better resolved via api > > > access... > > > > What stuff are you referring to? My test setup uses bash scripts that call > > emerge with various USE-flag combinations and then protocol failures. > > Which is a crappy way to be doing it, forced because zac hasn't gotten around > to merging the api branch... On the other hand, it is very close to what a user does. Set a weird random combination of USE-flags and emerge. > > Those > > scripts could more 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. > > Once those error codes are there, one can't just go rip them out when the > public api branch is merged. There's a maintenance burden you're ignoring > there. > > Regardless, it's a better use of time integrating the API crap in rather than > adding yet another hacky attempt to work around the lack of it. @portage, can you comment on this? How big is the maintenance burden?
(In reply to comment #4) > @portage, can you comment on this? How big is the maintenance burden? It doesn't seem like it would be much of a burden. The return code is already passed around appropriately, so the only difference will be setting it to the appropriate magic values at each of the places where it detects an error and returns.
