On Thu, Sep 13, 2018 at 05:15:48PM -0400, Jeremy Bicha wrote: > 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.
Ok, please feel free to close the bug about FHS compliance that I filed. > > 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. Oh, I don't really encourage deleting directories, I just allow it, that's all. > But if > that can't be done, I think we would be happy enough to apply a patch > to implement the trigger workaround. Have you considered a simple mkdir -p involved-opt-directory in the postrm? Thanks.