[arch-general] .desktop and install files in general & Eclipse package not complete?
Hi all, I already asked this at the forums, but didn't get an answer yet, so I'll re-explain my question(s) here. I just want to master creating packages with .desktop files and icon theme, but I think what I find and what is suggested differ significantly. In the GNOME Package Guidelines there's a section about .desktop files and the like. [1] It states that running update-desktop-database -q during post_install and post_remove is recommended (note that it doesn't state it's *required*). However, the Eclipse package doesn't do that. [2] It even doesn't depend on hicolor-icon-theme, as is required when issuing gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor during post_install (namcap didn't complain about this dependency, as it usually does, like about mars-mips: [3] mars-mips E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache (there are other issues with that package, about which I'll inform the package maintainer at a later moment)). On a second thought, issuing $ pacman -Qo gtk-update-icon-cache /usr/bin/gtk-update-icon-cache is owned by gtk-update-icon-cache 2.24.23-1 So shouldn't those packages with an icon theme depend on gtk-update-icon-cache instead of just on hicolor-icon-theme? Is the Eclipse package wrong or is the Wiki not complete (also note that the recommended install file of gedit [4] isn't that complete: it doesn't contain a call to gtk-update-icon-cache as it doesn't contain a hicolor icon theme; perhaps we should look for another example)? When the former is the case, I'll file a bug report. Else, please explain to me what to do with icon themes and .desktop files. I hope I expressed myself clearly. Regards, Marcel [1] https://wiki.archlinux.org/index.php/GNOME_Package_Guidelines#.desktop_files [2] https://projects.archlinux.org/svntogit/packages.git/tree/eclipse/repos/extr... [3] https://aur.archlinux.org/packages/mars-mips/ [4] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/gedit.instal...
On 2014-05-06 08:45, Marcel Korpel wrote:
Hi all,
I already asked this at the forums, but didn't get an answer yet, so I'll re-explain my question(s) here. I just want to master creating packages with .desktop files and icon theme, but I think what I find and what is suggested differ significantly.
In the GNOME Package Guidelines there's a section about .desktop files and the like. [1] It states that running
update-desktop-database -q
during post_install and post_remove is recommended (note that it doesn't state it's *required*). However, the Eclipse package doesn't do that. [2]
Have you bothered finding out what that command actually does? Once you do, you'd see that it's useless in this case.
It even doesn't depend on hicolor-icon-theme, as is required when issuing
gtk-update-icon-cache -q -t -f /usr/share/icons/hicolor
during post_install (namcap didn't complain about this dependency, as it usually does, like about mars-mips: [3]
mars-mips E: Files in /usr/share/icons/hicolor but no call to gtk-update-icon-cache or xdg-icon-resource to update the icon cache
(there are other issues with that package, about which I'll inform the package maintainer at a later moment)).
On a second thought, issuing
$ pacman -Qo gtk-update-icon-cache /usr/bin/gtk-update-icon-cache is owned by gtk-update-icon-cache 2.24.23-1
So shouldn't those packages with an icon theme depend on gtk-update-icon-cache instead of just on hicolor-icon-theme?
eclipse depends on gtk2, which depends on gtk-update-icon-cache, which depends on hicolor-icon-theme. The deps are already satisfied, which is why namcap didn't complain.
Is the Eclipse package wrong or is the Wiki not complete (also note that the recommended install file of gedit [4] isn't that complete: it doesn't contain a call to gtk-update-icon-cache as it doesn't contain a hicolor icon theme; perhaps we should look for another example)? When the former is the case, I'll file a bug report. Else, please explain to me what to do with icon themes and .desktop files.
If it doesn't install an icon, there's obviously no need to call gtk-update-icon-cache.
I hope I expressed myself clearly.
Regards, Marcel
[1] https://wiki.archlinux.org/index.php/GNOME_Package_Guidelines#.desktop_files [2] https://projects.archlinux.org/svntogit/packages.git/tree/eclipse/repos/extr... [3] https://aur.archlinux.org/packages/mars-mips/ [4] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/gedit.instal...
On Tue, May 6, 2014 at 5:55 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On 2014-05-06 08:45, Marcel Korpel wrote:
update-desktop-database -q […] Have you bothered finding out what that command actually does? Once you do, you'd see that it's useless in this case.
Ah, it's only necessary to update the MIME cache, so files with a certain extension are automatically loaded within a certain application? Sorry, I don't use a desktop environment, so I didn't know what the behaviour was.
$ pacman -Qo gtk-update-icon-cache /usr/bin/gtk-update-icon-cache is owned by gtk-update-icon-cache 2.24.23-1
So shouldn't those packages with an icon theme depend on gtk-update-icon-cache instead of just on hicolor-icon-theme? eclipse depends on gtk2, which depends on gtk-update-icon-cache, which depends on hicolor-icon-theme. The deps are already satisfied, which is why namcap didn't complain.
So, about eclipse: it isn't necessary, but in general: the Wiki should say that gtk-update-icon-cache should be included as a dependency (if it isn't satisfied by something else) instead of hicolor-icon-theme, which doesn't provide gtk-update-icon-cache. Am I right?
Is the Eclipse package wrong or is the Wiki not complete (also note that the recommended install file of gedit [4] isn't that complete: it doesn't contain a call to gtk-update-icon-cache as it doesn't contain a hicolor icon theme; perhaps we should look for another example)? If it doesn't install an icon, there's obviously no need to call gtk-update-icon-cache.
No, of course not, but the Wiki says: "The gedit package contains a very generic install file". However, the gedit install file isn't as generic as claimed: it isn't targeted at updating the icon cache. Regards, Marcel
On 2014-05-06 11:10, Marcel Korpel wrote:
On Tue, May 6, 2014 at 5:55 PM, Doug Newgard <scimmia@archlinux.info> wrote:
On 2014-05-06 08:45, Marcel Korpel wrote:
update-desktop-database -q […] Have you bothered finding out what that command actually does? Once you do, you'd see that it's useless in this case.
Ah, it's only necessary to update the MIME cache, so files with a certain extension are automatically loaded within a certain application? Sorry, I don't use a desktop environment, so I didn't know what the behaviour was.
$ pacman -Qo gtk-update-icon-cache /usr/bin/gtk-update-icon-cache is owned by gtk-update-icon-cache 2.24.23-1
So shouldn't those packages with an icon theme depend on gtk-update-icon-cache instead of just on hicolor-icon-theme? eclipse depends on gtk2, which depends on gtk-update-icon-cache, which depends on hicolor-icon-theme. The deps are already satisfied, which is why namcap didn't complain.
So, about eclipse: it isn't necessary, but in general: the Wiki should say that gtk-update-icon-cache should be included as a dependency (if it isn't satisfied by something else) instead of hicolor-icon-theme, which doesn't provide gtk-update-icon-cache. Am I right?
If you're going to run a program, it obviously needs to be a dependency.
Is the Eclipse package wrong or is the Wiki not complete (also note that the recommended install file of gedit [4] isn't that complete: it doesn't contain a call to gtk-update-icon-cache as it doesn't contain a hicolor icon theme; perhaps we should look for another example)? If it doesn't install an icon, there's obviously no need to call gtk-update-icon-cache.
No, of course not, but the Wiki says: "The gedit package contains a very generic install file". However, the gedit install file isn't as generic as claimed: it isn't targeted at updating the icon cache.
That section is very out of date. Looks like the substance hasn't really changed since it was first created in 2008, even though the install file has changed. The pkgname variable referenced hasn't even existed since 2011.
Regards, Marcel
participants (2)
-
Doug Newgard
-
Marcel Korpel