Hello packagers,
I have problems interpreting Packaging Guidelines section File and Directory Ownership [1] for icons application place in %{_datadir}/icons/hicolor. I ran into this during package review for dosbox-x [2], but I think the issue is more general than that, because many applications add their icons to the (default, fallback) hicolor theme.
So the package places application's icon to %{_datadir}/icons/hicolor/scalable/apps/dosbox-x.svg. From the guidelines, it is clear that for all directories in the chain, one of the following has to be true:
1. Package owns the directory 2. A dependency package owns the directory 3. _filesystem_, _man_ or "other explicitly created -filesystem package" own the directory
Item 3 takes care of %{_datadir}/icons part, because that is included in _filesystem_. The remainder hicolor/scalable/apps is unclear for me. Method 1 could be used. But there is also package _hicolor-icon-theme_. Is that package an "explicitly created -filesystem package", so method 3 could be used? That would feel natural, because hicolor is the fallback theme that must exist according to freedesktop.org specification.
Related but separate question about the guidelines: Section Unowned Directories:Inaccessible Directories [3] discusses a problem that is only relevant to Fedora < 9 and RHEL < 5.3. It does not really contain any information that is relevant today. Should that section simply be removed?
Otto
[1]: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_file_and_directo... [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1919639 [3]: https://docs.fedoraproject.org/en-US/packaging-guidelines/UnownedDirectories...
On 28. 03. 21 14:11, Otto Urpelainen wrote:> Item 3 takes care of %{_datadir}/icons part, because that is included in
_filesystem_. The remainder hicolor/scalable/apps is unclear for me. Method 1 could be used. But there is also package _hicolor-icon-theme_. Is that package an "explicitly created -filesystem package", so method 3 could be used? That would feel natural, because hicolor is the fallback theme that must exist according to freedesktop.org specification.
Yes. hicolor-icon-theme acts like an "other explicitly created -filesystem package" here. It only contains the directories, cache and triggers.
Maybe we should explicitly mention it in the guidelines, because it is a very common situation.
Miro Hrončok kirjoitti 28.3.2021 klo 15.47:
On 28. 03. 21 14:11, Otto Urpelainen wrote:> Item 3 takes care of %{_datadir}/icons part, because that is included in
_filesystem_. The remainder hicolor/scalable/apps is unclear for me. Method 1 could be used. But there is also package _hicolor-icon-theme_. Is that package an "explicitly created -filesystem package", so method 3 could be used? That would feel natural, because hicolor is the fallback theme that must exist according to freedesktop.org specification.
Yes. hicolor-icon-theme acts like an "other explicitly created -filesystem package" here. It only contains the directories, cache and triggers.
Maybe we should explicitly mention it in the guidelines, because it is a very common situation.
Thank you, that makes sense. I will prepare a pull request to the guidelines shortly. And also for fedora-review (if feasible) so it would stop complaining about this situation.
Otto
On Sun, Mar 28, 2021 at 2:48 PM Miro Hrončok mhroncok@redhat.com wrote:
On 28. 03. 21 14:11, Otto Urpelainen wrote:> Item 3 takes care of %{_datadir}/icons part, because that is included in
_filesystem_. The remainder hicolor/scalable/apps is unclear for me. Method 1 could be used. But there is also package _hicolor-icon-theme_. Is that package an "explicitly created -filesystem package", so method 3 could be used? That would feel natural, because hicolor is the fallback theme that must exist according to freedesktop.org specification.
Yes. hicolor-icon-theme acts like an "other explicitly created -filesystem package" here. It only contains the directories, cache and triggers.
Maybe we should explicitly mention it in the guidelines, because it is a very common situation.
Weird, I was under the impression that to fix the "unowned directory problem" you had to "just" add "Requires: hicolor-icon-theme" to the package shipping the icons. All my GUI application packages that ship their own icons do that. Why would that dependency not be necessary?
Fabio
On Sun, Mar 28, 2021 at 2:48 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
Weird, I was under the impression that to fix the "unowned directory problem" you had to "just" add "Requires: hicolor-icon-theme" to the package shipping the icons.
That is correct.
All my GUI application packages that ship their own icons do that. Why would that dependency not be necessary?
I think we are misunderstanding each other here.
Miro Hrončok kirjoitti 28.3.2021 klo 23.23:
On Sun, Mar 28, 2021 at 2:48 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
Weird, I was under the impression that to fix the "unowned directory problem" you had to "just" add "Requires: hicolor-icon-theme" to the package shipping the icons.
That is correct.
All my GUI application packages that ship their own icons do that. Why would that dependency not be necessary?
I think we are misunderstanding each other here.
So the correct method is "Requires: hicolor-icon-theme". The reason I initially understood this differently was this:
1. the guidelines give _filesystem_ and "other explicitly created filesystem packages" the same standing in this phrase: "any directories owned by the filesystem, man, or other explicitly created -filesystem packages" 2. _filesystem_ is not given special treatment anywhere 3. you do not do "Requires: filesystem" to get /usr/bin created
Which sounds like a contrived argument, but really I really was just trying to figure out how it should be done.
I already opened a pull request to clarify this, I have to redo it.
Otto
On 29. 03. 21 0:11, Otto Urpelainen wrote:
Miro Hrončok kirjoitti 28.3.2021 klo 23.23:
On Sun, Mar 28, 2021 at 2:48 PM Miro Hrončok <mhroncok(a)redhat.com> wrote:
Weird, I was under the impression that to fix the "unowned directory problem" you had to "just" add "Requires: hicolor-icon-theme" to the package shipping the icons.
That is correct.
All my GUI application packages that ship their own icons do that. Why would that dependency not be necessary?
I think we are misunderstanding each other here.
So the correct method is "Requires: hicolor-icon-theme". The reason I initially understood this differently was this:
- the guidelines give _filesystem_ and "other explicitly created filesystem
packages" the same standing in this phrase: "any directories owned by the filesystem, man, or other explicitly created -filesystem packages" 2. _filesystem_ is not given special treatment anywhere 3. you do not do "Requires: filesystem" to get /usr/bin created
Which sounds like a contrived argument, but really I really was just trying to figure out how it should be done.
I already opened a pull request to clarify this, I have to redo it.
OK, I now see where I made this more confusing.
Let me clarify:
1) hicolor-icon-theme "acts" like a filesystem package 2) except you need to Require it
Many other packages work like this (e.g. python-jupyter-filesystem, python3-jaraco).
------
Random idea: Let's have a database of those and generate the requirement on them automatically?
Miro Hrončok kirjoitti 29.3.2021 klo 10.05:
On 29. 03. 21 0:11, Otto Urpelainen wrote:
Which sounds like a contrived argument, but really I really was just trying to figure out how it should be done.
I already opened a pull request to clarify this, I have to redo it.
OK, I now see where I made this more confusing.
Let me clarify:
- hicolor-icon-theme "acts" like a filesystem package
- except you need to Require it
Many other packages work like this (e.g. python-jupyter-filesystem, python3-jaraco).
No, I was confused from the start, all the discussion here is making it more clear. Here is the pull request attempting to word the guidelines better:
https://pagure.io/packaging-committee/pull-request/1061
Random idea: Let's have a database of those and generate the requirement on them automatically?
I might take a look at some point, for fun mainly.
Otto
Thanks for sharing this interesting and informative information
High Adventure https://highadventure.in/
packaging@lists.fedoraproject.org
-
Fabio Valentini -
High Adventure -
Miro Hrončok -
Otto Urpelainen