Bug#888549: Should dpkg remove /etc/opt/ on package removal?

[Jeremy Bicha]

Giullem and others,

We have an issue and we are having some difficulty figuring out the
best way to fix it.

Background
=========
chrome-gnome-shell is an add-on package to allow several web browsers
to install and uninstall GNOME Shell extensions by clicking buttons at
https://extensions.gnome.org/

One of the supported browsers upstream is Google Chrome, which Google
installs to /opt/chrome/ . According to the FHS, that means its
configuration should be stored in /etc/opt/chrome/ . To support Google
Chrome, chrome-gnome-shell must install files to /etc/opt/chrome/ .

Until late last year, Debian's chrome-gnome-shell package was unable
to support Google Chrome because it was a lintian auto-reject to ship
files in /etc/opt/ .

I recently uploaded chrome-gnome-shell 9-2 with Google Chrome support.
It triggers a pipuparts regression (for itself and all its reverse
depends like debian-edu) because when chrome-gnome-shell is removed,
dpkg removes /etc/opt/ since no other package in Debian owns
/etc/opt/.

base-files creates that directory (in its postinst) because the
Maintainer believes that that directory should be present in new
installs for better FHS compliance but that sysadmins should be
allowed to remove that directory if they like.

Suggested Fixes
============

1. "Google Chrome should not install to /opt/ " IMO, I don't think
this is necessary.

2. "chrome-gnome-shell should not install anything to /etc/opt/
regardless of whether that means not supporting Google Chrome". IMO
this causes unnecessary harm to Google Chrome users on Debian. Anyway,
if people support this position, then the lintian auto-reject should
be re-established.

3. "base-files should own /etc/opt/" Rejected by the base-files maintainer.

4. "base-files should introduce a separate, recommended package to own
directories like /etc/opt/". Also rejected by the base-files
maintainer.

5. "piuparts could ignore the removal of /etc/opt/" Rejected by the
piuparts maintainer

6. "chrome-gnome-shell could re-create /etc/opt/ in its postrm". Feels
a bit ugly to me, but maybe acceptable if we can't find a better
solution.

7. How about if dpkg special-case the /etc/opt/ directory and not
remove it when removing a package that ships files there?

References
=========
https://bugs.debian.org/888243 The base-files bug for this issue
https://bugs.debian.org/888549 The chrome-gnome-shell bug for this issue
https://bugs.debian.org/840235 Removal of the autoreject
https://bugs.debian.org/840804 Bug complaining that Debian's
chrome-gnome-shell didn't support Google Chrome

http://www.pathname.com/fhs/pub/fhs-2.3.html#ETCOPTCONFIGURATIONFILESFOROPT

https://piuparts.debian.org/sid/fail/chrome-gnome-shell_9-2.log
"ERROR: FAIL: After purging files have disappeared: /etc/opt/ owned
by: chrome-gnome-shell"


Thanks,
Jeremy Bicha