Hi!

On Fri, 2024-02-16 at 04:37:47 +0100, Christoph Anton Mitterer wrote:
> Package: dpkg
> Version: 1.22.4
> Severity: normal

> dpkg-query manpage says:
> EXIT STATUS
>        0   The requested query was successfully performed.
> 
>        1   The  requested  query  failed  either fully or partially, due to no
>            file  or  package   being   found   (except   for   --control-path,
>            --control-list and --control-show were such errors are fatal).
> 
>        2   Fatal  or unrecoverable error due to invalid command-line usage, or
>            interactions with the system, such as  accesses  to  the  database,
>            memory allocations, etc.

> E.g.:
>  $ dpkg-query --showformat='${db:Status-Status}' --show --list 2>/dev/null ; 
> echo $?
>  2
> looks good, as does
>  $ dpkg-query --showformat='${db:Status-Status}' --show not-existing-package 
> 2>/dev/null ; echo $?
>  1
> 
> But e.g.
>  $ dpkg-query --showformat='${db:Status-Statu' --show  2>/dev/null ; echo $?
>  1
> causes also 1, though it fails because of the syntax error in the format 
> string.
> 
> Shouldn't that be a 2?

Yeah, I think so. I've looked into this now, and there are several
problems in the dpkg-query code, one is that several of the action
functions only ever return 1 for any direct failure they handle, the
other is that even if they returned something else, the main()
function coerces that return code into a boolean, so it always ends
up being 0 or 1. I'll have a pass over the entire code, and correct
all instances and queue this for the next upload. Thanks!

> At least it seems to make it impossible to definitely find out whether a 
> package
> is not installed (respectively not existant).

Exactly.

> btw. it will also not fail at all in cases like:
>  $ dpkg-query --showformat='${db:Status-Statu}' --show  2>/dev/null ; echo $?
>  0
> where the field doesn't exist. Not sure whether that’s desired or not

This is used for field names, be them real or virtual, so erroring out
on fields that do not exist would seem bad. But there's the
distinction between the real fields and virtual ones, where the latter
always contain a colon. So I guess I could make the latter, at least
warn if they do not exist. My main concern with making them errors, is
that this would break backwards and/or forwards compatibility, where
you could not use a new or renamed field with old or new releases.

Thanks,
Guillem

Reply via email to