Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant

Jeremy Bicha jbicha at debian.org
Thu Sep 13 22:15:48 BST 2018


On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila <sanvila at unex.es> wrote:
> What I said is that no sane package in Debian/main should need to put
> files directly in /etc/opt. That's an oddity, a very unorthodox thing,
> it would be like a Debian package in main putting stuff directly in /opt.

chrome-gnome-shell (in this case) is an addon for the Google Chrome
web browser. Since Chrome installs to /opt/ (which is encouraged by
FHS), /etc/opt/ is the only standards-compliant location for
chrome-gnome-shell to ship the configuration files it needs to provide
its core functionality.

There is no reason this functionality cannot be offered in Debian. We
got complaints when we supported other browsers but not Google Chrome.

> I filed the bug because I believe it's the root of the problem you
> have with piuparts, but in either case, feel free to disagree on that
> one and claim FHS compliance, as far as you don't ask other people to
> fix the consequences of putting files in /etc/opt.

I am asking for help. I have never created or dealt with noawait
triggers so I don't know how to implement Guillem's suggested
workaround.

We talked about this a week ago in the Debian GNOME team. I believe
the team generally thinks it would be a lot simpler for base-files or
a similar package to just provides these directories and stop
encouraging sysadmins to delete directories they don't like. But if
that can't be done, I think we would be happy enough to apply a patch
to implement the trigger workaround.

Thanks,
Jeremy Bicha



More information about the pkg-gnome-maintainers mailing list