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

  • Bug#1076511: dpkg: should --force-remove-essential imply --force-remove

    From Simon McVittie@1:229/2 to All on Wed Jul 17 16:40:01 2024
    XPost: linux.debian.bugs.dist
    From: smcv@collabora.com

    Package: dpkg
    Version: 1.21.22
    Severity: wishlist

    Before Debian trixie, login was Essential; now it's merely Protected
    (included in normal installations, but removable).

    In minimal container environments where logins and package management
    are not required functionality, it can be useful to remove Essential and Protected packages. For example, https://salsa.debian.org/smcv/flatdeb
    (used in Valve's Steam Runtime) is intended for single-user, Flatpak-like
    app containers with an immutable /usr, so it removes login, passwd
    and eventually dpkg to save some space in the container, using dpkg --force-remove-essential to make that happen. (Obviously this breaks some normal things in that container, but that's OK for my particular use-case.)

    When login became non-Essential, this regressed: now that login is
    Protected, `dpkg --force-remove-essential --purge login` refuses to
    remove it, even though being Protected is "weaker" than being Essential:

    2024/07/15 04:30:34 platformize | dpkg: error processing package login (--purge):
    2024/07/15 04:30:34 platformize | this is a protected package; it should not be removed

    and even though it does allow Essential packages to be removed:

    2024/07/15 04:30:34 platformize | dpkg: warning: overriding problem because --force enabled:
    2024/07/15 04:30:34 platformize | dpkg: warning: this is an essential package; it should not be removed

    I think it might make sense for --force-remove-essential to automatically enable the "weaker" option --force-remove-protected - if we're in a
    scenario where removing Essential packages is OK, then it's certainly OK
    to remove packages like login that are only Protected.

    A workaround is to detect the dpkg version in use, and if it's >= 1.20.1,
    add --force-remove-protected to the dpkg command-line.

    smcv

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Guillem Jover@1:229/2 to Simon McVittie on Thu Jul 18 01:40:01 2024
    XPost: linux.debian.bugs.dist
    From: guillem@debian.org

    Hi!

    On Wed, 2024-07-17 at 15:24:36 +0100, Simon McVittie wrote:
    Package: dpkg
    Version: 1.21.22
    Severity: wishlist

    Before Debian trixie, login was Essential; now it's merely Protected (included in normal installations, but removable).

    In minimal container environments where logins and package management
    are not required functionality, it can be useful to remove Essential and Protected packages. For example, https://salsa.debian.org/smcv/flatdeb
    (used in Valve's Steam Runtime) is intended for single-user, Flatpak-like
    app containers with an immutable /usr, so it removes login, passwd
    and eventually dpkg to save some space in the container, using dpkg --force-remove-essential to make that happen. (Obviously this breaks some normal things in that container, but that's OK for my particular use-case.)

    When login became non-Essential, this regressed: now that login is
    Protected, `dpkg --force-remove-essential --purge login` refuses to
    remove it, even though being Protected is "weaker" than being Essential:

    I don't think protected can be considered weaker in absolute terms, I
    think this depends on the context. For the packaging system, Essential
    is indeed the stronger field, so in a normal chroot scenario that will
    also be stronger than Protected. For the host system Protected is going
    to be used among other things to preserve bootability, which I'd say makes
    it the stronger field, as for a user, being unable to boot is going to be
    worse than being able to use dpkg, and once booted the packaging system
    can be more easily recovered (probably).

    2024/07/15 04:30:34 platformize | dpkg: error processing package login (--purge):
    2024/07/15 04:30:34 platformize | this is a protected package; it should not be removed

    and even though it does allow Essential packages to be removed:

    2024/07/15 04:30:34 platformize | dpkg: warning: overriding problem because --force enabled:
    2024/07/15 04:30:34 platformize | dpkg: warning: this is an essential package; it should not be removed

    I think it might make sense for --force-remove-essential to automatically enable the "weaker" option --force-remove-protected - if we're in a
    scenario where removing Essential packages is OK, then it's certainly OK
    to remove packages like login that are only Protected.

    See above.

    A workaround is to detect the dpkg version in use, and if it's >= 1.20.1,
    add --force-remove-protected to the dpkg command-line.

    The expected way to detect whether you might need to pass that option
    is to use «dpkg --assert-protected-field» and checking the exit code,
    which is the way apt is doing that too.

    I assume part of the rationale for filing this report might have been so
    that the logic in the caller can be simplified, by making it not care
    about the support in dpkg *and* the state of packages that change over releases. But the semantics of the requested change does not seem ideal,
    and a tool that explicitly removes a list of packages is going to be
    somewhat distro/release specific anyway. So I'm inclined to close this
    report.

    Thanks,
    Guillem

    --- SoupGate-Win32 v1.05
    * Origin: you cannot sedate... all the things you hate (1:229/2)
  • From Guillem Jover@1:229/2 to Guillem Jover on Thu Jul 18 01:50:01 2024
    XPost: linux.debian.bugs.dist
    From: guillem@debian.org

    Hi!

    On Thu, 2024-07-18 at 01:30:48 +0200, Guillem Jover wrote:
    A workaround is to detect the dpkg version in use, and if it's >= 1.20.1, add --force-remove-protected to the dpkg command-line.

    The expected way to detect whether you might need to pass that option
    is to use «dpkg --assert-protected-field» and checking the exit code,
    which is the way apt is doing that too.

    Ah, sorry, it looks like apt never used that option, because it either
    waited for the dpkg in the same release to have the support, or assumed
    that packages would only add the field after a dpkg in stable had the
    support. So it does not really need to care as much.

    Thanks,
    Guillem

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