1. Forum
  2. Usenet
  3. LINUX.DEBIAN.MAINT.DPKG

  • Bug#1064036: dpkg: wrong dpkg-query exit status on syntax error?

    From Christoph Anton Mitterer@1:229/2 to All on Fri Feb 16 04:50:01 2024
    XPost: linux.debian.bugs.dist
    From: [email protected]

    [SoupGate killed MIME-encoded file 00000000.ATT (2158 bytes)]

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Christoph Anton Mitterer@1:229/2 to Guillem Jover on Fri Feb 16 05:50:01 2024
    XPost: linux.debian.bugs.dist
    From: [email protected]

    Hey Guillem.

    On Fri, 2024-02-16 at 05:26 +0100, Guillem Jover wrote:

    Thanks!

    Well rather: thank you, for your constant efforts to DPKG and the whole ecosystem.


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

    Exactly.

    Maybe it would also be worth to elaborate on:
    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).

    My understanding would have been, that e.g. when searching for a
    package, 1 would in practise mean that it doesn't exist at all (when
    looking from APT’s PoV) respectively is in the state 'not-installed'.

    So I guess for end-users it might be helpful to be told that, i.e. that
    these two things (non-existing from APT) and non-installed are the same
    from DPKG’s PoV, and would trigger 1.

    Also perhaps notifying somewhere that 'not-installed' will never really
    show up anywhere as a printed query result.



    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.

    Warnings are at last difficult to use when scripting.

    And btw: it also succeeds if there's no colon, e.g.:
    $ dpkg-query --showformat='${foobar}' --show 2>/dev/null ; echo $?

    0


    Thanks,
    Chris.

    PS: In the dpkg-query manpage, there's:
    Desired action:

    u = Unknown
    i = Install
    h = Hold
    r = Remove
    p = Purge

    Package status:

    n = Not-installed
    c = Config-files
    H = Half-installed
    U = Unpacked
    F = Half-configured
    W = Triggers-awaiting
    t = Triggers-pending
    i = Installed

    Error flags:

    <empty> = (none)
    R = Reinst-required

    I think, when these are actually printed, the full names are all
    lowercase, i.e. installed not Installed ... might perhaps make sense to
    align that?

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Guillem Jover@1:229/2 to Christoph Anton Mitterer on Fri Feb 16 05:40:01 2024
    XPost: linux.debian.bugs.dist
    From: [email protected]

    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

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)