Usage of /etc/opt/ and /opt is discouraged, however for some applications that ship a native application component together with a Chromium/Chrome browser extension (Firefox keeps addons and manifests in /usr/share and thus does not suffer from this) it is needed to package native-messaging-host manifests and extension install hints.
Clarification would be regarding Chromium - since it is provided by Fedora packages and in order to provide support for it in addon, /etc/chromium/ subfolder usage should be fine by the FPC?
Is it acceptable to package Chrome extension install hint and native messaging host manifest for Chrome? While Chrome is not officially packaged and/or supported by Fedora, Google is providing a repository tailored specifically to fedora and package is installed in the /opt/google/chrome which is in accordance with LANANA. As could be seen from existing packages like chrome-chrome-shell and fedora user agent addon - it is happening at the moment, but I would like to be 100% sure.
The questions are relating to webextension-token-signing package, that includes a native component and a WebExtension on the browser side to enable digital signatures on the Web supporting Estonian (and other) ID hardware card.
To your first question, I don't know of any part of the guidelines which prevents the creation of a subdirectory under /etc to store configuration files. This is quite common, But I'm not sure how that is relevant to your questions.
As to #2, you obviously can't have hard dependencies against things in other repositories, but I can't think of any restriction on putting some extra files that might be used by some other package if it happened to be installed. Of course, your package can't itself put things in /opt/google. or /etc/opt or anything like that. The chrome-gnome-shell package is not in compliance with the packaging guidelines and should not have been approved.
So, as far as I understand addons for Firefox and Chromium are in compliance, but Chrome is a no-go?
I don't think addons which work with Chrome would be forbidden. I would think it difficult to have an addon which is only for Chrome because it would be pointless without a dependency.
Of course, if Chrome refuses to look anywhere on the system besides somewhere under /opt/google then there wouldn't be any way for a package to put files there and remain in compliance with the packaging guidelines. I have no idea at all if that's the case, but it would be rather unfortunate and short-sighted if it were.
Currently native messaging host (that allows access to pcscd daemon (and consequentially - to the hardware cards for cryptographic operations) and it requires usage of manifest for any browser wishing to use it to tie together native component and extension id.
The idea was to enable usage of the addon in all browser by installing one package (native host + manifests for all three browsers and extension for Firefox and install hints for Chromium and Chrome).
Locations for Chromium:
Install hint: /usr/share/chromium/extensions/ckjefchnfjhjfedoccjbhjpbncimppeg.json
Native messaging host manifest: /etc/chromium/native-messaging-hosts/
Locations for Chrome:
Installation hint: /opt/google/chrome/extensions/ckjefchnfjhjfedoccjbhjpbncimppeg.json
Manifest location: /etc/opt/chrome/native-messaging-hosts/
Aforementioned chrome-gnome-shell is shipping native host and addons for Chrome + Chromium, which I took as as an example as was hoping to do ship together.
Sure, the idea is fine, but if Chrome really won't look anywhere else then, well, that's unfortunate and broken. You would think that it could at least look for configuration things in a place where configuration files go.
And yes, chrome-gnome-shell is violating the guidelines. I had already filed https://bugzilla.redhat.com/show_bug.cgi?id=1577352
Note that our Chromium packages also put things in /opt/google. I would have thought that spot would have avoided doing that since he wrote the restrictions on opt in the first place.
Thanks for bringing this to our attention. I'm not sure what we can really do about it given the recent push for third party repos from other parts of the project. Packaging guidelines always get ignored when someone thinks they have a good idea.
Certainly we could explicitly approve an exception for /opt/google. I guess personally I wouldn't particularly care one way or the other. I still do think it's idiotic that chrome won't look outside of one Google-reserved directory for the information it wants.
Metadata Update from @tibbs:
- Issue tagged with: meeting
Thanks for clearing that up.
I'll package for Firefox and Chromium only for the time being.
chrome-gnome-shell intends to ignore bugs about this, I guess. Oh, well, not much we can do.
I think this raises two interesting questions:
Should Fedora packages offer support for open-source Chrome addons if Chromium package is available among other things?
Addons like https://github.com/tpopela/fedora-user-agent-chrome that are shipped in default installation of Fedora Workstation, that offer Chrome support out of the box despite Chrome not being packaged for Fedora.
And if the answer to the first one is "yes", then it raises the question of how should the described sistuations be tackled. One possible solution could be to file a bug against Chrome, as it's looking for install hints in the /usr/share/google-chrome/extensions, but looks for native messaging manifests in /etc/opt/chrome/ while storing package files in /opt/google/chrome
This is not a pressing issue, but seems like there is already some difference in opinion in the community, so a weighted discussion could be in order?
Or would it make sense to apply for an exception for all WebExtension addons that plan to support both Chromium and Chrome as a separate packaging committee ticket and have a broader discussion there?
We discussed this at this weeks meeting (http://meetbot.fedoraproject.org/fedora-meeting-1/2018-05-17/fpc.2018-05-17-16.00.txt):
Metadata Update from @james:
- Issue untagged with: meeting
- Issue assigned to tibbs
- Issue tagged with: writeup
For the record, that location (regardless of how poor a choice it is) is documented as the proper location by Google: https://developer.chrome.com/apps/nativeMessaging
An exception to the use of /etc/opt by Chrome native messaging extensions was approved.
Metadata Update from @tibbs:
- Issue untagged with: writeup
- Issue tagged with: announce
Metadata Update from @tibbs:
- Issue untagged with: announce
- Issue close_status updated to: accepted
- Issue status updated to: Closed (was: Open)
to comment on this ticket.