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

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

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

Jeremy Bicha-5
Santiago, can we revisit this?

Debian Policy § 9.1.1 since 4.1.5.0 requires compliance with FHS 3.0
and I don't see any listed exception for /etc/opt/ .

FHS 3.0 § 3.7.2 requires /etc/opt/ . (§ 3.2 also requires /opt)

References
----------------
- https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-structure
- https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#etcHostspecificSystemConfiguration
- https://bugs.debian.org/93390

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

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

Santiago Vila
On Thu, Sep 13, 2018 at 01:23:32PM -0400, Jeremy Bicha wrote:
> Santiago, can we revisit this?
>
> Debian Policy § 9.1.1 since 4.1.5.0 requires compliance with FHS 3.0
> and I don't see any listed exception for /etc/opt/ .
>
> FHS 3.0 § 3.7.2 requires /etc/opt/ . (§ 3.2 also requires /opt)

We pass the FHS compliance tests, for newly installed systems, which is
where the tests should be performed, base-files *provides* those
directories, but if you remove them (either directly or indirectly),
then it is your duty to restore them, not mine.

Please reassign. This is not a bug in base-files.

Thanks.

Reply | Threaded
Open this post in threaded view
|

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

Jeremy Bicha-5
On Thu, Sep 13, 2018 at 1:31 PM Santiago Vila <[hidden email]> wrote:
> Please reassign. This is not a bug in base-files.

Let's specifically talk about https://bugs.debian.org/888549 . You
opened that bug claiming that chrome-gnome-shell wasn't compliant with
FHS but it is compliant.

> We pass the FHS compliance tests, for newly installed systems, which is
> where the tests should be performed, base-files *provides* those
> directories, but if you remove them (either directly or indirectly),
> then it is your duty to restore them, not mine.

Respectfully, chrome-gnome-shell isn't removing anything. The
pipuparts issue preventing chrome-gnome-shell from migrating to
Testing is a bug caused by your unusual interpretation of the word
"required" in FHS.

Thanks,
Jeremy Bicha

Reply | Threaded
Open this post in threaded view
|

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

Santiago Vila
In reply to this post by Jeremy Bicha-5
On Thu, Sep 13, 2018 at 01:23:32PM -0400, Jeremy Bicha wrote:

> References
> ----------------
> [...]
> - https://bugs.debian.org/93390

Are you serious?

Such bug was in 2001-04-10, but in 2001-11-09 I modified base-files
to provide the opt directories, this is from the changelog:

base-files (2.2.14) unstable; urgency=low

  * Created /opt, /etc/opt and /var/opt in the first install.
    They are mentioned in FHS 2.1 and required in FHS 2.2 (Closes: #118505).

You can check that those directories exist in any newly installed Debian system.

Creating directories in the postinst is a completely acceptable way to
provide FHS compliance, and in fact, it is sometimes necessary to
accomodate for mount points and similar things, see this changelog
entry for example:

base-files (7.7) unstable; urgency=low

  * The directory /mnt is not included inside base-files.deb anymore.
    Instead, it is created by postinst the very first time base-files
    is installed (by debootstrap), or when upgrading from an earlier
    base-files version. This should make the usual upgrade at every point
    release to work even if /mnt is a stale mount point. Closes: #763405.


So, to summarize again: No, this is not a bug in base-files. I'm very
sorry that this implementation detail causes trouble for you, but I
firmly believe that whatever problem you have with it does not require a
modification in base-files to be solved, or a restriction in the freedom
to remove a directory when you don't need it.

Can we reassing this already, please?

Thanks.

Reply | Threaded
Open this post in threaded view
|

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

Santiago Vila
In reply to this post by Jeremy Bicha-5
On Thu, Sep 13, 2018 at 01:38:19PM -0400, Jeremy Bicha wrote:
> On Thu, Sep 13, 2018 at 1:31 PM Santiago Vila <[hidden email]> wrote:
> > Please reassign. This is not a bug in base-files.
>
> Let's specifically talk about https://bugs.debian.org/888549 . You
> opened that bug claiming that chrome-gnome-shell wasn't compliant with
> FHS but it is compliant.

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.

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.

Thanks.

Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
In reply to this post by Santiago Vila
On Thu, Sep 13, 2018 at 10:28:18PM +0200, Santiago Vila wrote:
> On Thu, Sep 13, 2018 at 01:23:32PM -0400, Jeremy Bicha wrote:
>
> > References
> > ----------------
> > [...]
> > - https://bugs.debian.org/93390
>
> Are you serious?
[...]
> Can we reassing this already, please?

for those watching along:
- #93390 is closed.
- #888549 is assigned to chrome-gnome-shell

Please let's all calm down and find the right technical solution for
#888549, which is titled "chrome-gnome-shell: Please don't use /etc/opt,
it's not FHS-compliant" which doesnt seem to be correct anymore with
todays version of FHS which debian-policy mandates.

So, close #888549 or retitle to what?


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Santiago Vila
On Thu, Sep 13, 2018 at 08:41:49PM +0000, Holger Levsen wrote:
> On Thu, Sep 13, 2018 at 10:28:18PM +0200, Santiago Vila wrote:

> > Can we reassing this already, please?
>
> for those watching along:
> - #93390 is closed.
> - #888549 is assigned to chrome-gnome-shell

I was referring to #888243, which is not a bug in base-files.

Thanks.

Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
On Thu, Sep 13, 2018 at 10:47:16PM +0200, Santiago Vila wrote:

> On Thu, Sep 13, 2018 at 08:41:49PM +0000, Holger Levsen wrote:
> > On Thu, Sep 13, 2018 at 10:28:18PM +0200, Santiago Vila wrote:
>
> > > Can we reassing this already, please?
> >
> > for those watching along:
> > - #93390 is closed.
> > - #888549 is assigned to chrome-gnome-shell
>
> I was referring to #888243, which is not a bug in base-files.
thanks for pointing this out. I guess this is because we are cc:ing #888549
and #888546 here, and #888546 is merged with #888243, #888549 is not merged
with anything.

Anyhow,

- #888243/#888546 is assigned to base-files and in 888243 is called " Lack of /opt in
  base-files causes piuparts issues for in-house packages" while 888546
  is called "gnome-chrom-shell: After purging files have disappeared:
  /etc/opt/ owned by: chrome-gnome-shell"
- #888549 is assigned to gnome-chrome-shell and is called
  "chrome-gnome-shell: Please don't use /etc/opt, it's not
  FHS-compliant"

So it seems to me, that

a.) using /opt/etc and shipping files there is fine today and piuparts
    should not complain here
b.) thus #888243/#888546 should be reassigned to piuparts
c.) #888549 should be closed or merged with #888243/#888546

Am I missing something?


on a related note, why do merged bugs have different titles?

--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Jeremy Bicha-5
In reply to this post by Santiago Vila
On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

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

Santiago Vila
On Thu, Sep 13, 2018 at 05:15:48PM -0400, Jeremy Bicha wrote:

> On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila <[hidden email]> 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 | Threaded
Open this post in threaded view
|

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

Santiago Vila
In reply to this post by Holger Levsen-2
On Thu, Sep 13, 2018 at 08:59:39PM +0000, Holger Levsen wrote:

> a.) using /opt/etc and shipping files there is fine today and piuparts
>     should not complain here

Could you briefly explain in which way the most recent FHS is more
permissive than previous releases?

If we allow using /etc/opt in Debian packages, I would like to think
that it would be only to support packages not in Debian already using
it, (like the present case), not an open door to use /etc/opt widely.

(In other words, IMHO, a warning from piuparts would still be desirable).

Thanks.

Reply | Threaded
Open this post in threaded view
|

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

Jonathan Nieder
In reply to this post by Jeremy Bicha-5
Hi,

Jeremy Bicha wrote:
> On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila <[hidden email]> 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.

Since Google Chrome is not part of Debian, shouldn't this
functionality be offered in contrib, not Debian?

[...]
>                                                              But if
> that can't be done, I think we would be happy enough to apply a patch
> to implement the trigger workaround.

For what it's worth (especially since this is about integrating with a
non-Debian package), makes sense to me.

Thanks,
Jonathan

Reply | Threaded
Open this post in threaded view
|

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

Santiago Vila
In reply to this post by Santiago Vila
unmerge 888546
reassign 888546 chrome-gnome-shell
thanks

With this unmerge and reassign, I'm keeping each bug where they were
originally reported.

Holger, this one (#888546) is the bug that you reported. If you think
it is really a bug in piuparts, feel free to reassign again.

[ After this I will close #888243 (the bug in base-files) ].

You can still Cc: me if you want (but other than "mkdir -p directory"
in postrm, I don't have any better idea).

Thanks.

Reply | Threaded
Open this post in threaded view
|

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

Simon McVittie-7
In reply to this post by Jonathan Nieder
On Thu, 13 Sep 2018 at 14:57:47 -0700, Jonathan Nieder wrote:
> Jeremy Bicha wrote:
> > There is no reason this functionality cannot be offered in Debian. We
> > got complaints when we supported other browsers but not Google Chrome.
>
> Since Google Chrome is not part of Debian, shouldn't this
> functionality be offered in contrib, not Debian?

That would be appropriate if chrome-gnome-shell *only* integrated with
Chrome, but it does the same things for Chromium and Firefox, which
are in main. The name only starts with "chrome" because that's what its
upstream developer calls it (and the binary package would probably be
webext-gnome-shell if it was packaged today).

    smcv

Reply | Threaded
Open this post in threaded view
|

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

Russ Allbery-2
In reply to this post by Jonathan Nieder
Jonathan Nieder <[hidden email]> writes:
> Jeremy Bicha wrote:

>> 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.

> Since Google Chrome is not part of Debian, shouldn't this
> functionality be offered in contrib, not Debian?

chrome-gnome-shell supports all of Chromium, Chrome, and Firefox in the
same package, two of which are in Debian.  It only installs one file in
/etc/opt for Chrome, namely:

/etc/opt/chrome/native-messaging-hosts/org.gnome.chrome_gnome_shell.json

Splitting that single config file into a separate contrib package feels
like overkill here.  It shouldn't hurt anything on a system without Chrome
and it doesn't create any sort of dependency on Chrome, which is the
normal case for contrib.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
In reply to this post by Jeremy Bicha-5
On Thu, Sep 13, 2018 at 05:15:48PM -0400, Jeremy Bicha wrote:
> On Thu, Sep 13, 2018 at 4:40 PM Santiago Vila <[hidden email]> 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.
 
This makes sense to me.

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

also :)

> > 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.

debian-edu-artwork is a package which uses noawait triggers. I also
found the lintian hints quite helpful:

debian-edu-artwork$ rgrep noawait *
debian/changelog:    into -noawait ones. Thanks lintian and #debian-qa.
debian/changelog:  * d-e-a-softwaves.triggers: Use interest-noawait to avoid triggers cycle.
debian/debian-edu-artwork-lines.triggers:interest-noawait /usr/share/plasma/desktoptheme
debian/debian-edu-artwork-softwaves.triggers:interest-noawait /usr/share/plasma/desktoptheme
debian/debian-edu-artwork-softwaves.triggers:interest-noawait /etc/plymouth
debian/debian-edu-artwork-softwaves.triggers:interest-noawait /usr/share/doc/debian-edu-artwork-lines


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
In reply to this post by Santiago Vila
On Fri, Sep 14, 2018 at 12:01:07AM +0200, Santiago Vila wrote:
> Holger, this one (#888546) is the bug that you reported. If you think
> it is really a bug in piuparts, feel free to reassign again.

well, this bug is about a file/directory vanishing and I think it is
correct that piuparts complains about those.


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Holger Levsen-2
In reply to this post by Santiago Vila
On Thu, Sep 13, 2018 at 11:35:50PM +0200, Santiago Vila wrote:
> On Thu, Sep 13, 2018 at 08:59:39PM +0000, Holger Levsen wrote:
> > a.) using /opt/etc and shipping files there is fine today and piuparts
> >     should not complain here
> Could you briefly explain in which way the most recent FHS is more
> permissive than previous releases?

I'm not going to dig up and compare different FHS versions now, but this
is what I recall from when FHS 3.0 was announced..

But then, I just checked
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s13.html and
http://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch03s07.html#etcoptConfigurationFilesForOpt
and noticed that neither speaks of /opt/etc, just /etc/opt...

> if we allow using /etc/opt in Debian packages, I would like to think
> that it would be only to support packages not in Debian already using
> it, (like the present case), not an open door to use /etc/opt widely.
>
> (In other words, IMHO, a warning from piuparts would still be desirable).

piuparts(.d.o) doesnt really have the concept of warnings, there are
either errors or not. But maybe this is something lintian could detect?


--
cheers,
        Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

signature.asc (849 bytes) Download Attachment