[opensuse-packaging] Where to define some rpm macros needed by many packages?
Hi, I'm facing three cases where many packages should do something in %post/%postun but usually don't do anything because it's some manual work, and I want to provide macros to make it easier to fix this. The three cases are: + when installing a .desktop file, update-desktop-database should be called + when installing an icon in the hicolor theme, gtk-update-icon-cache should be called + when installing some mime information in /usr/share/mime, update-mime-database should be called I could put macros for this in the respective packages (desktop-file-utils, gtk2 and shared-mime-info), but I'm not really sure it's good to force every package installing a .desktop to have a BuildRequires on desktop-file-utils... On the other hand, I don't feel those macros should live in the rpm package itself either. Any idea what would be the best solution? (Btw, the best long-term solution is some trigger in rpm when a file get installed in a directory, but I've been waiting for this for a long time and I don't see it moving...) Thanks, Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2010/8/7 Vincent Untz <vuntz@opensuse.org>:
Hi,
I'm facing three cases where many packages should do something in %post/%postun but usually don't do anything because it's some manual work, and I want to provide macros to make it easier to fix this.
The three cases are:
+ when installing a .desktop file, update-desktop-database should be called
I should reverify, but I think KDE ignores it (it has its own MIME cache and has to look at .desktop files anyway for the "InitialPreference" field). There is something really using it?
+ when installing an icon in the hicolor theme, gtk-update-icon-cache should be called
Wasn't decided it was a bad idea (https://bugzilla.novell.com/395056 and related, plus http://old-en.opensuse.org/Packaging/Scriptlet_Snippets#GTK.2B_icon_cache)? GTK should be fixed instead? KDE doesn't needs anything similar...
(Btw, the best long-term solution is some trigger in rpm when a file get installed in a directory, but I've been waiting for this for a long time and I don't see it moving...)
I didn't look at them in detail, but aren't "Collections" (http://lists.opensuse.org/zypp-devel/2010-06/msg00004.html) what's needed? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le samedi 07 août 2010, à 15:31 +0200, Cristian Morales Vega a écrit :
2010/8/7 Vincent Untz <vuntz@opensuse.org>:
Hi,
I'm facing three cases where many packages should do something in %post/%postun but usually don't do anything because it's some manual work, and I want to provide macros to make it easier to fix this.
The three cases are:
+ when installing a .desktop file, update-desktop-database should be called
I should reverify, but I think KDE ignores it (it has its own MIME cache and has to look at .desktop files anyway for the "InitialPreference" field). There is something really using it?
At least all the glib-based world uses it. I could change the question to this one: "What doesn't use it except KDE?" :-)
+ when installing an icon in the hicolor theme, gtk-update-icon-cache should be called
Wasn't decided it was a bad idea (https://bugzilla.novell.com/395056 and related, plus http://old-en.opensuse.org/Packaging/Scriptlet_Snippets#GTK.2B_icon_cache)? GTK should be fixed instead? KDE doesn't needs anything similar...
SuSEconfig is not called if zypper is used, so the old way doesn't work. And we use this in GTK+ to improve performance. If somebody knows how to improve performance when looking for icons without using this cache, I'd be happy to talk to upstream about changing this.
(Btw, the best long-term solution is some trigger in rpm when a file get installed in a directory, but I've been waiting for this for a long time and I don't see it moving...)
I didn't look at them in detail, but aren't "Collections" (http://lists.opensuse.org/zypp-devel/2010-06/msg00004.html) what's needed?
Could work, but I'm unsure if it's okay to have collections that cover all packages? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
2010/8/7 Vincent Untz <vuntz@opensuse.org>:
Le samedi 07 août 2010, à 15:31 +0200, Cristian Morales Vega a écrit :
2010/8/7 Vincent Untz <vuntz@opensuse.org>:
Hi,
I'm facing three cases where many packages should do something in %post/%postun but usually don't do anything because it's some manual work, and I want to provide macros to make it easier to fix this.
The three cases are:
+ when installing a .desktop file, update-desktop-database should be called
I should reverify, but I think KDE ignores it (it has its own MIME cache and has to look at .desktop files anyway for the "InitialPreference" field). There is something really using it?
At least all the glib-based world uses it. I could change the question to this one: "What doesn't use it except KDE?" :-)
Ok. But notice that you want to put in scriplets what is now in SuSEconfig.desktop-file-utils... you probably want to also put SuSEconfig.glib2 since it's very related (MIME database vs default applications, dependent of MIME types) Would be great to do both things in a single pass. Right now each one is doing a full scan of every .desktop file.
+ when installing an icon in the hicolor theme, gtk-update-icon-cache should be called
Wasn't decided it was a bad idea (https://bugzilla.novell.com/395056 and related, plus http://old-en.opensuse.org/Packaging/Scriptlet_Snippets#GTK.2B_icon_cache)? GTK should be fixed instead? KDE doesn't needs anything similar...
SuSEconfig is not called if zypper is used, so the old way doesn't work.
I know. But wasn't it causing serious problems in the installer?
And we use this in GTK+ to improve performance. If somebody knows how to improve performance when looking for icons without using this cache, I'd be happy to talk to upstream about changing this.
Again, from memory. KDE runs its cache system when it starts, and then a daemon continuously looks for changes. I have never listen a complain about KDE start time. Not sure how this relates to pure Qt apps...
(Btw, the best long-term solution is some trigger in rpm when a file get installed in a directory, but I've been waiting for this for a long time and I don't see it moving...)
I didn't look at them in detail, but aren't "Collections" (http://lists.opensuse.org/zypp-devel/2010-06/msg00004.html) what's needed?
Could work, but I'm unsure if it's okay to have collections that cover all packages?
No idea. But it seems things are starting to move here. If something is going to change, since we have eight months until 11.4 perhaps we could aim to the correct, long-term solution? -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Sat, 7 Aug 2010 19:08:03 +0200 Cristian Morales Vega <cmorve69@yahoo.es> wrote:
Again, from memory. KDE runs its cache system when it starts, and then a daemon continuously looks for changes. I have never listen a complain about KDE start time.
JFTR, I know it's offtopic here. I stopped complaining 5 years ago, and it was going downhill since then. Lubos did some speedup at that time, but today it is abysmally slow again. (logging in takes much longer than booting the system on FACTORY). Fortunately I only reboot/relogin for major updates and those don't happen too frequently... -- Stefan Seyfried "Theory and practice sometimes clash. And when that happens, theory loses. Every single time." -- Linus Torvalds -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Saturday 07 of August 2010, Vincent Untz wrote:
Le samedi 07 août 2010, à 15:31 +0200, Cristian Morales Vega a écrit :
2010/8/7 Vincent Untz <vuntz@opensuse.org>:
+ when installing an icon in the hicolor theme, gtk-update-icon-cache should be called
Wasn't decided it was a bad idea (https://bugzilla.novell.com/395056 and related, plus http://old-en.opensuse.org/Packaging/Scriptlet_Snippets#GTK.2B_icon_cache )? GTK should be fixed instead? KDE doesn't needs anything similar...
SuSEconfig is not called if zypper is used, so the old way doesn't work. And we use this in GTK+ to improve performance. If somebody knows how to improve performance when looking for icons without using this cache, I'd be happy to talk to upstream about changing this.
You could update the cache on-demand, as KDE does, instead of running it from SuSEconfig (which is actually sometimes pretty annoying on a KDE system with few rarely-used Gtk apps). -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le lundi 09 août 2010, à 14:41 +0200, Lubos Lunak a écrit :
On Saturday 07 of August 2010, Vincent Untz wrote:
Le samedi 07 août 2010, à 15:31 +0200, Cristian Morales Vega a écrit :
2010/8/7 Vincent Untz <vuntz@opensuse.org>:
+ when installing an icon in the hicolor theme, gtk-update-icon-cache should be called
Wasn't decided it was a bad idea (https://bugzilla.novell.com/395056 and related, plus http://old-en.opensuse.org/Packaging/Scriptlet_Snippets#GTK.2B_icon_cache )? GTK should be fixed instead? KDE doesn't needs anything similar...
SuSEconfig is not called if zypper is used, so the old way doesn't work. And we use this in GTK+ to improve performance. If somebody knows how to improve performance when looking for icons without using this cache, I'd be happy to talk to upstream about changing this.
You could update the cache on-demand, as KDE does, instead of running it from SuSEconfig (which is actually sometimes pretty annoying on a KDE system with few rarely-used Gtk apps).
I'm sorry, can you elaborate: + when you say "on-demand", do I understand right that you are talking about a user cache, and not a system-wide cache? (FWIW, upstream prefers a system-wide cache for this) + why it SuSEconfig annoying on a KDE system with few rarely-used GTK+ apps? It it SuSEconfig itself? Is it gtk-update-icon-cache? Is it because people have to manually run it? Is it because it takes time after installing packages? Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On Monday 09 of August 2010, Vincent Untz wrote:
Le lundi 09 août 2010, à 14:41 +0200, Lubos Lunak a écrit :
On Saturday 07 of August 2010, Vincent Untz wrote:
SuSEconfig is not called if zypper is used, so the old way doesn't work. And we use this in GTK+ to improve performance. If somebody knows how to improve performance when looking for icons without using this cache, I'd be happy to talk to upstream about changing this.
You could update the cache on-demand, as KDE does, instead of running it from SuSEconfig (which is actually sometimes pretty annoying on a KDE system with few rarely-used Gtk apps).
I'm sorry, can you elaborate:
+ when you say "on-demand", do I understand right that you are talking about a user cache, and not a system-wide cache? (FWIW, upstream prefers a system-wide cache for this)
User cache. If you'd want a system cache, I don't see any other way than a setuid wrapper that run the tool as root. BTW I don't quite see the point of having a huge system cache, do you happen to know how that is supposed to make anything better?
+ why it SuSEconfig annoying on a KDE system with few rarely-used GTK+ apps? It it SuSEconfig itself? Is it gtk-update-icon-cache? Is it because people have to manually run it? Is it because it takes time after installing packages?
Because creating the icon cache can take long, after installing packages. And note that on-demand would save the trouble with people having to run anything manually. -- Lubos Lunak openSUSE Boosters team, KDE developer l.lunak@suse.cz , l.lunak@kde.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le lundi 09 août 2010, à 23:18 +0200, Lubos Lunak a écrit :
On Monday 09 of August 2010, Vincent Untz wrote:
Le lundi 09 août 2010, à 14:41 +0200, Lubos Lunak a écrit :
You could update the cache on-demand, as KDE does, instead of running it from SuSEconfig (which is actually sometimes pretty annoying on a KDE system with few rarely-used Gtk apps).
I'm sorry, can you elaborate:
+ when you say "on-demand", do I understand right that you are talking about a user cache, and not a system-wide cache? (FWIW, upstream prefers a system-wide cache for this)
User cache. If you'd want a system cache, I don't see any other way than a setuid wrapper that run the tool as root.
The setuid wrapper is not really an option, I guess. Nobody likes that :-)
BTW I don't quite see the point of having a huge system cache, do you happen to know how that is supposed to make anything better?
Why would it be huge? It's really just a cache for some system data, so there's no reason to not make it system-wide. I don't claim it's "better". It's just a way to share more things between users, since there's no reason to not share this.
+ why it SuSEconfig annoying on a KDE system with few rarely-used GTK+ apps? It it SuSEconfig itself? Is it gtk-update-icon-cache? Is it because people have to manually run it? Is it because it takes time after installing packages?
Because creating the icon cache can take long, after installing packages.
It doesn't take that long if it's done only once, does it? Does it really make a big difference compared to, say, downloading 5MB for a package?
And note that on-demand would save the trouble with people having to run anything manually.
Agree, we don't want to force people to run something manually. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Am Samstag 07 August 2010, 14:57:28 schrieb Vincent Untz:
I'm facing three cases where many packages should do something in %post/%postun but usually don't do anything because it's some manual work, and I want to provide macros to make it easier to fix this.
It is possible to put a macro.* file int /etc/rpm. There are already many of them containing macros specific for fdupes, perl, python, KDE and other things.
[...]
Herbert -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le samedi 07 août 2010, à 15:52 +0200, Herbert Graeber a écrit :
Am Samstag 07 August 2010, 14:57:28 schrieb Vincent Untz:
I'm facing three cases where many packages should do something in %post/%postun but usually don't do anything because it's some manual work, and I want to provide macros to make it easier to fix this.
It is possible to put a macro.* file int /etc/rpm. There are already many of them containing macros specific for fdupes, perl, python, KDE and other things.
I know that. My question is: in which package should this macros.XXX file live, especially since I don't think it's a very good idea to have it live in desktop-file-utils/shared-mime-info/etc. (since it means adding unnessecary BuildRequires). Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
On 2010-08-07 16:02:17 +0200, Vincent Untz wrote:
Le samedi 07 août 2010, à 15:52 +0200, Herbert Graeber a écrit :
Am Samstag 07 August 2010, 14:57:28 schrieb Vincent Untz:
I'm facing three cases where many packages should do something in %post/%postun but usually don't do anything because it's some manual work, and I want to provide macros to make it easier to fix this.
It is possible to put a macro.* file int /etc/rpm. There are already many of them containing macros specific for fdupes, perl, python, KDE and other things.
I know that. My question is: in which package should this macros.XXX file live, especially since I don't think it's a very good idea to have it live in desktop-file-utils/shared-mime-info/etc. (since it means adding unnessecary BuildRequires).
strictly speaking those buildrequires are not unnessecary, as your package is using those macros. so if e.g. suse_update_desktop_files needs desktop-file-utils now. the macro should maybe moved from the rpm package to that package. darix -- openSUSE - SUSE Linux is my linux openSUSE is good for you www.opensuse.org -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
Le dimanche 08 août 2010, à 05:11 +0200, Marcus Rueckert a écrit :
On 2010-08-07 16:02:17 +0200, Vincent Untz wrote:
I know that. My question is: in which package should this macros.XXX file live, especially since I don't think it's a very good idea to have it live in desktop-file-utils/shared-mime-info/etc. (since it means adding unnessecary BuildRequires).
strictly speaking those buildrequires are not unnessecary, as your package is using those macros. so if e.g. suse_update_desktop_files needs desktop-file-utils now. the macro should maybe moved from the rpm package to that package.
This macro lives in the update-desktop-files package :-) So we could (ab)use this package for the .desktop-related macros, indeed. Vincent -- Les gens heureux ne sont pas pressés. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org
participants (6)
-
Cristian Morales Vega -
Herbert Graeber -
Lubos Lunak -
Marcus Rueckert -
Stefan Seyfried -
Vincent Untz