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

  • Bug#1085073: dpkg: please expose no-triggers mode to hooks

    From Guillem Jover@1:229/2 to Aaron M. Ucko on Mon Oct 14 13:40:01 2024
    XPost: linux.debian.bugs.dist
    From: [email protected]

    Hi!

    On Sun, 2024-10-13 at 21:35:05 -0400, Aaron M. Ucko wrote:
    Package: dpkg
    Version: 1.22.11
    Severity: normal
    X-Debbugs-Cc: [email protected]

    As dpkg's man page notes, complex apt runs can yield multiple
    invocations of dpkg and hence also of dpkg-level hooks. As (at
    minimum) I and the reporters of #775503 and #931344 have found, this arrangement can interact somewhat poorly with debian-security-support,
    which then prompts in the middle of long upgrades (or buries short
    reports when using the readline debconf frontend); I'm copying its maintainers accordingly.

    I see that apt arranges to defer triggers for efficiency on that
    front. Having --no-triggers outright disable post-invoke hooks could plausibly break some setups, but perhaps it could result in invoking
    them with some special environment setting so that they could then
    cleanly bail unless they truly needed to run quite so promptly.

    Ideally, pre-invoke hooks should analogously be able to identify an
    apt run's first dpkg invocation. However, that may be easier said
    than done, and I'm not sure it's as much of a concern in practice.

    Hmm, it seems to me you are asking for a feature so that the user of
    the dpkg hooks can infer how an upper layer tool driving dpkg is
    operating it. This feels like the wrong approach to design such an
    interface as it ties it with how currently apt operates, where ideally
    in the future apt would be able to perform a single or a couple calls
    and delegate everything to dpkg itself, which this proposed usage might
    then prevent. Instead I think that, what would be better is to switch
    the user from dpkg hooks to apt hooks?

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Aaron M. Ucko@1:229/2 to All on Mon Oct 14 03:50:01 2024
    XPost: linux.debian.bugs.dist
    From: [email protected]

    Package: dpkg
    Version: 1.22.11
    Severity: normal
    X-Debbugs-Cc: [email protected]

    As dpkg's man page notes, complex apt runs can yield multiple
    invocations of dpkg and hence also of dpkg-level hooks. As (at
    minimum) I and the reporters of #775503 and #931344 have found, this arrangement can interact somewhat poorly with debian-security-support,
    which then prompts in the middle of long upgrades (or buries short
    reports when using the readline debconf frontend); I'm copying its
    maintainers accordingly.

    I see that apt arranges to defer triggers for efficiency on that
    front. Having --no-triggers outright disable post-invoke hooks could
    plausibly break some setups, but perhaps it could result in invoking
    them with some special environment setting so that they could then
    cleanly bail unless they truly needed to run quite so promptly.

    Ideally, pre-invoke hooks should analogously be able to identify an
    apt run's first dpkg invocation. However, that may be easier said
    than done, and I'm not sure it's as much of a concern in practice.

    Thanks!

    -- Package-specific info:

    -- System Information:
    Debian Release: trixie/sid
    APT prefers testing-debug
    APT policy: (500, 'testing-debug'), (500, 'stable-security'), (500, 'stable-debug'), (500, 'proposed-updates-debug'), (500, 'oldstable-security'), (500, 'testing'), (300, 'unstable-debug'), (300, 'unstable')
    Architecture: amd64 (x86_64)
    Foreign Architectures: i386, x32

    Kernel: Linux 6.11.2-amd64 (SMP w/8 CPU threads; PREEMPT)
    Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
    Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
    Shell: /bin/sh linked to /usr/bin/dash
    Init: systemd (via /run/systemd/system)
    LSM: AppArmor: enabled

    Versions of packages dpkg depends on:
    ii libbz2-1.0 1.0.8-6
    ii libc6 2.40-3
    ii liblzma5 5.6.2-2
    ii libmd0 1.1.0-2
    ii libselinux1 3.7-3
    ii libzstd1 1.5.6+dfsg-1
    ii tar 1.35+dfsg-3
    ii zlib1g 1:1.3.dfsg+really1.3.1-1

    dpkg recommends no packages.

    Versions of packages dpkg suggests:
    ii apt 2.9.8
    pn debsig-verify <none>

    -- debconf-show failed

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Aaron M. Ucko@1:229/2 to Guillem Jover on Mon Oct 14 18:10:01 2024
    XPost: linux.debian.bugs.dist
    From: [email protected]

    Guillem Jover <[email protected]> writes:

    Hmm, it seems to me you are asking for a feature so that the user of
    the dpkg hooks can infer how an upper layer tool driving dpkg is
    operating it. This feels like the wrong approach to design such an
    interface as it ties it with how currently apt operates, where ideally
    in the future apt would be able to perform a single or a couple calls
    and delegate everything to dpkg itself, which this proposed usage might
    then prevent. Instead I think that, what would be better is to switch
    the user from dpkg hooks to apt hooks?

    Thanks for the quick reply and considering my request! I'd definitely
    welcome more delegation to dpkg. However, if and when that happens,
    dpkg should perhaps still run hooks every (internal) round to retain
    current semantics, so extending the hook interface may be in order
    regardless. I concede that the variable name shouldn't necessarily
    mention triggers explicitly; something like DPKG_HOOK_LAST_ROUND=1 would
    be more futureproof. Upon consideration, I suppose it would be best for
    the relevant logic to be formally independent of triggers altogether and instead reflect a new command-line argument apt (or cupt) would then
    pass, something like --phase={start,middle,end}.

    --
    Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/[email protected]

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