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

[Guillem Jover]

Hi!

On Sat, 2018-01-27 at 09:46:32 -0500, Jeremy Bicha wrote:
> Background
> =========

> 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/ .

I don't find the FHS very clear on the /etc/opt topic, TBH. Can for
example third-party applications read also /etc/<package> if it's
present? That could perhaps be another solution, don't know.

> 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/.

Correct.

> 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.

Yes, to me this rationale make sense, I guess because I think I've even
found myself cleaning up these kind of dirs on some of my systems! :)

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

Third-party apps should be able to install into /opt, IMO.

> 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.

I think there are two parts to this. One is whether the package should
install files there at all. The other is whether it should ship such
paths as being owned in the dpkg sense.

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

This could be an easy option, but might annoy users that want to get
rid of those dirs.

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

One additional problem with this approach is that to be able to remove
specific dirs, one would need to add then one package per such
optional dir? :)

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

I agree that piuparts should not special case this.

> 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.

This might require to preserve sysadmin changes, so if the sysadmin
has removed the directory before package installation, it should get
removed after package removal too.

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

That's not an option. I'd very much like to keep dpkg be as path
neutral as possible by not starting to special case anything which
is distribution-specific.



I think the ideal solution could imply making it possible to mark
pathnames as optional, so that base-files would then mark /opt and
friends as such, and the sysadmin could remove them, and those would
not get restored on upgrade. Of course the interaction with something
like chrome-gnome-shell then becomes a bit tricky, because dpkg then
might need to track the state of the dir when the other package
appeared, so I'm not sure how that'd play out.

For a currently implementable solution, I think you could just ship
those files elsewhere, say just /etc. Then install a noawait trigger
on /opt/<chrome-whatever> or similar, and when that gets activated
create a symlink in /etc/opt/<chrome-whatever> from the maintscript
to the place with the actual content.

This has the property that it does not pollute the /etc/opt namespace,
does not trip on any optional path removal, nor piuparts nor lintian
errors, as it will only appear in case the chrome package gets installed.
I think leaving the /etc/opt/ directory (but not its symlinked subdir)
behind after removing is also probably acceptable here.

Would this solve all your problems? Did I miss anything?

Thanks,
Guillem