On 15.03.11 22:48, Jeff Johnson wrote:

> [...]
> Yes a known problem. There are code paths throughout RPM which
> cannot return error codes properly without breaking API/ABI
> or because its work-in-progress.
> 
> The above 2 cases seem pretty innocent, but its not going to
> surprise me to see more serious problems under a rpmgi also returning 0.
> 
> IIRC, there was discussion (from Mark Hatle? arekm?) abt 2 rpmgi failure cases
> on rpm-devel@ here like August 2007. cvs annotate lib/rpmgi.c should show the 
> time frame.
> 
> I can wire up error codes (or find details why not) for
> those two error cases if you wish.
> 
> With -i (and -q and -K) using the rpmgi iterator, its a bit more
> complex than just coding up
>       if (open(....) < 0)
>               return errno
> because of the interlocked state in the rpmgi (Generalized Iterator).

Ok, understood.

> I can look at rpm-5.1.9 (and all later versions) tonight if you want.
> 
> I need to revisit the rpmgi pretty soon anyways, because 
> hdlists-as-used-by-mandriva
> aren't the same as hdlists-as-used-by-rpm and its almost time to
> fix (Mandriva's not rpm's) divergence.
> 
> But lemme ask first:
> 
> Does openpkg need/use status returned from rpm? Is it ok to switch to
> EXIT_FAILURE instead of (what rpm has traditionally done) return
>       no of failing "packages"
> Drilling EXIT_FAILURE everywhere has been on my todo++ list for abt 2 years,
> just, well, its gonna be messy and tedious (but returning no. of pkgs in 8 
> bits
> started to become silly in ~2001).

OpenPKG itself doesn't use the RPM return code, but users of OpenPKG
try to rely on the RPM return code for their deployment automatisms.
Currently they have to use slow workarounds (query the RPM database
after each RPM operation to see whether it succeeded, for instance)
because they cannot rely on a !=0 return code from RPM.

So, I think a general EXIT_FAILURE would be fully sufficient. It
is just important that a !=0 return code exists in case of failures.
If the !=0 return code can be more specific (various numbers for
various failure cases) would be even cooler, but this is not really
required. But a !=0 exit code in case of any errors really would be
required.

Currently I've to still keep OpenPKG at 5.1.9, so I even would need
a patch or at least some hints how I can fix this error code for
5.1.9. If you fix it in HEAD with a single commit I also can try
to backport this to 5.1.9. Although I've to confess that I've not
hacked on RPM internals for many months now (and had to code in
Java, Scala, etc) and certainly need some support from you, Jeff ;-)

So, I really appreciate help from you, Jeff. Many thanks.

                                       Ralf S. Engelschall
                                       r...@engelschall.com
                                       www.engelschall.com
______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

Reply via email to