Re: Bug#888549: chrome-gnome-shell: Please don't use /etc/opt, it's not FHS-compliant
On Thu, Sep 13, 2018 at 05:15:48PM -0400, Jeremy Bicha wrote:
> On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila <sanvila@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.
Reply to: