Dear Maintainers,

I was trying to remove a 3rd party package with apt and it deleted the /opt
folder as well. I have identified that it's due to this package incorrectly
identified /opt as part of its file tree, so dpkg removed /opt as well, seeing
it has no other folders/files in it. Indeed this remove operation didn't cause
any data loss, however this also prevents any further 3rd party packages from
being installed to /opt as well.

Now, of course the main responsibility lies on sloppy packaging practice
of the 3rd party package. But to make sure such packages won't cause problem
for the OS users, would it make sense for add safeguards that make
dpkg ignore such remove requests when removing these folders
might cause system usability problems? (Like /usr/lib/modules and /usr/sbin )

Note that though the following information said I have dpkg 1.22.22 installed,
conflicting the information in header, I have manually verified on dpkg 1.23.7.

Hi!

This is due to a combination of factors:

  a) base-files only creates the directory on first install, as
     explained in its «/usr/share/doc/base-files/FAQ», so that people
     can removed the directory and dpkg will not recreate it on
     upgrade. See https://bugs.debian.org/888243 for example.
  b) dpkg does not support marking specific directories as optional,
     so that they get created on first installation, but if they get
     removed by an administrator then they do not appear again.

Once we have metadata tracking, we can then add support for this, and
then base-files could be changed to own those paths, but making them
optional.

Thanks,
Guillem