Le samedi 07 août 2010, à 15:31 +0200, Cristian Morales Vega a écrit :

2010/8/7 Vincent Untz :

...

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

On Sat, 7 Aug 2010 19:08:03 +0200 Cristian Morales Vega 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

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 :

...

 + 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

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

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

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