On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila <sanv...@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