Should dpkg remove /etc/opt/ on package removal?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Should dpkg remove /etc/opt/ on package removal?

Jeremy Bicha-5
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

Reply | Threaded
Open this post in threaded view
|

Re: 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

Reply | Threaded
Open this post in threaded view
|

Re: Should dpkg remove /etc/opt/ on package removal?

Simon McVittie-7
On Mon, 29 Jan 2018 at 22:52:32 +0100, Guillem Jover wrote:
> On Sat, 2018-01-27 at 09:46:32 -0500, Jeremy Bicha wrote:
> > 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.

If Chrome doesn't actually do this, then wondering whether it would be
allowed to do so doesn't necessarily help us: chrome-gnome-shell supports
(among others) Google Chrome, not a hypothetical better browser similar
to Google Chrome. One of the notable properties that Chrome has is
that as a proprietary binary, we have very limited control over how it
behaves. It's Google's choice where it will install and which integration
points it offers, not ours.

(Arguably there is a non-hypothetical better browser similar to Google
Chrome, and it's called Chromium - but Chrome has some functionality that
Chromium doesn't, so there are reasons to prefer each one over the other.)

    smcv