[Bug 2003789] Re: Cannot exclude read-only paths from dpkg, as they still cause dpkg to fail

[Łukasz Zemczak]

Pushed this to Debian: https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1030149 . Will now upload to lunar and as SRUs to
kinetic and jammy.

** Bug watch added: Debian Bug tracker #1030149
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1030149

** Also affects: dpkg (Ubuntu Jammy)
   Importance: Undecided
       Status: New

** Also affects: dpkg (Ubuntu Kinetic)
   Importance: Undecided
       Status: New

** Changed in: dpkg (Ubuntu Jammy)
   Importance: Undecided => High

** Changed in: dpkg (Ubuntu Kinetic)
   Importance: Undecided => Low

** Changed in: dpkg (Ubuntu)
       Status: New => Fix Committed

** Changed in: dpkg (Ubuntu Kinetic)
       Status: New => Won't Fix

** Changed in: dpkg (Ubuntu Jammy)
       Status: New => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to dpkg in Ubuntu.
https://bugs.launchpad.net/bugs/2003789

Title:
  Cannot exclude read-only paths from dpkg, as they still cause dpkg to
  fail

Status in dpkg package in Ubuntu:
  Fix Committed
Status in dpkg source package in Jammy:
  In Progress
Status in dpkg source package in Kinetic:
  Won't Fix

Bug description:
  [Impact]

  In certain very specific cases, certain directories on the filesystem
  can be read-only. As-is, this is problematic for dpkg in case some
  package wants to install files there - which is fine and expected. But
  when this situation is 'intentional', one might want to use --path-
  exclude for the selected paths. Currently, dpkg will *still* fail in
  such cases.

  The reason is that dpkg, before starting work on the package, checks
  for any dpkg interrupted transactions. It does that by performing a
  rename() on the dpkg tmp files on the selected path, and if there is
  none (by checking errno for ENOENT and ENOTDIR), it continues the
  operation. But in cases where the file-system is read only, the
  returned errno is EROFS, which is not handled and treated as if the
  file is there but unable to restore it.

  It feels like a valid case though - if the filesystem if readonly, we
  should not consider *this* as an error case. Without path-excludes,
  dpkg will fail at a different moment anyway. While if someone has a
  working setup where this path indeed should be read-only but excluded,
  we should let dpkg continue.

  [Test Case]

  Ideally, creating a setup where some directory (for instance,
  /lib/firmware) is read-only, and trying to install a package like
  alsa-topology-conf. The package installation should succeed without
  any files installed into /lib/firmware.

  [Regression Potential]

  As this is a change in dpkg, there's quite a lot that might go wrong.
  However, the change is rather limited. Problems can appear in handling
  of interrupted transactions, or by breaking package installation in
  overall.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/dpkg/+bug/2003789/+subscriptions