On Mar 15, 2011, at 5:18 PM, Ralf S. Engelschall wrote:

> I got a report that RPM (here the older version 5.1.9)
> does not return a failure code (!= 0) on some operations
> where a failure code is strongly expected (and where
> RPM 4.x still returned a failure code).
> From the report:
> 
> # openpkg rpm -i /tmp/asdf.rpm
> error: open of /tmp/asdf.rpm failed: No such file or directory
> # echo 0
> 0
> # touch /tmp/asdf.rpm
> # openpkg rpm -i /tmp/asdf.rpm
> # echo 0
> 0
> 
> You can just ignore here the "openpkg" run-time wrapper in
> the report as the same problem occurs also when calling the
> rpm(1) executable directly.
> 
> Before I investigate and jump deeper into the sources myself,
> is this a known problem (perhaps already fixed in versions > 5.1.9)?
> Does anybody have a clue why RPM still returns just 0 on those
> errors? Any hints welcome...
> 

OK, most of what you need is now checked-in (on the rpm-5_4 branch
to feed to "continuous integration" buildbots, I'll push it in
all the ususal places including back to -r rpm-5_1 as soon
as I can conferm I have done no harm).

The 2 test case -- while they may seem obvious -- actually aren't obvious
at all. Here's why:

RPM supports manifests from the CLI with --install et al for almost all
of this century.

The implementation is tricky because
        try to read as a *.rpm package.
        if the read-as-package fails, then assume a manifest,
        and parse through strings augmenting argv[].

The implementation is tricky because it forces the manifest parser to deal with
every possible form of input, without magic, or grammar or any other structural 
hints.

The next part is even trickier still, and has to do with how
RPM defines its exit code as "no. of failed items".

Let's assume you are assembling a collection of manifests of packages
named A and B. A is populated iff its "enterprise" linux, while B
is populated with all the usual "open sores" packages.

So you script up something like
        if this-is-enterprise-linux; then
            cp enterprise.manifest A
        fi
        cp opensores.manifest B

Now you tell me (for both the missing and the empty examples you have
provided)

        What _EXACTLY_ should be the exit code of
                rpm -Uvh A B

To make matters even more confusing, this invocation requires
a coin flip to decide if the exit status means SUCCESS/FAILURE

        echo "" > empty
        rpm -Uvh empty

The exit code is 0 (or was until I hot-wired everything to meet
dumbed down luser expectations in order to help close a bug report).

if you expected SUCCESS (and the coin flip was heads), then 0 is exactly what 
you expect.

If you expected FAILURE (and the coin flip was tails), then 0 is entirely 
consistent
with "no. of failed items" because there are no package items, only an empty 
manifest.

Meanwhile there's one other code path, with --query/--verify, to "fix". For 
extra
speshul painfulness, the rpmgi iterator is rewound and re-iterated with some 
--query/--verify
options, and I'm gonna need some vermouth on the rocks and a splash of chlorox 
to
deal with that.

Short answer: Your two exit cases now return 1 with -i and -K (which are the 
likeliest
points where some careful script kiddie might reasonably be surprised at a 0 
return code).

I do suggest that anyone who is reporting 0 exit codes from rpm as
a bug should be graduated "magna cum laude" and sent along to
schools of higher education like here:
        http://www.linux.com/archive/feed/118126
because sooner or later assuming manifests if its not a header is going
to have to be revisited.

I personally think that manifests, not *.rpm, MUST be supported on the RPM cli. 
There's
way too many packages around for *.rpm to do what you mean instead of what you 
want (sic).

hth

73 de Jeff




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

______________________________________________________________________
RPM Package Manager                                    http://rpm5.org
Developer Communication List                        rpm-devel@rpm5.org

Reply via email to