On 05/20/2010 10:56 AM, Rex Dieter wrote:

Anyway, given that, I've tried hard and failed to come up with any disadvantages to moving this (and the other update-* items) to %posttrans in general. Please do chime in, if I missed anything.

Seems sensible, we should discuss this next Wednesday.

~spot

On Thu, May 20, 2010 at 09:56:37AM -0500, Rex Dieter wrote:

Richard Hughes wrote:

...

As more applications convert from GConf to GSettings, Fedora packages are going to need to deal with schema files.

At the moment in gnome-color-manager I use this:

%post glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :

%postun glib-compile-schemas %{_datadir}/glib-2.0/schemas &> /dev/null || :

Although doing it for every single package seems like a waste of time. Maybe posttrans would be better in this case? Anyway, I think we need to sort out a policy and stick it on https://fedoraproject.org/wiki/Packaging:ScriptletSnippets before people start packaging applications that use GSettings schema files.

Let the discussion commence.

Thanks for the suggestions, I think %posttrans should be the way to go in general for stuff like this (I've been meaning to make a similar proposal to modify scriptletsnippets for update-desktop-database and update-mime-database for awhile).

Note that I agree with using %posttrans where it doesn't interfere with later package installs but there are two things to be wary of here:

1) %posttrans just moves the scriptlet to the ned of the transaction; It does not consolidate duplicate %posttrans scriptlets into a single command. That means that the speedups we get are mostly due to filesystem caching. People should be aware that compute heavy processes or things that don't fit in the filesystem cache will still be slow even if we put them into %posttrans.

The current GConf2 scriptlets are much more complex than the GSettings ones (behind the scenes) because GConf was unacceptably slow when there was no need to be (new version of a package has the same schema file as the old version but we were resyncing GConf anyway. The new scriptlets do away with that.)

2) Sometimes it can interfere and it's hard to tell from the 10,000 foot view of the Guidelines. For instance, GConf and GSettings seem like they can very easily interfere with later packages. There's nothing preventing me from writing an app that does some registration for other applications and also happens to use GSettings for my settings.

Perhaps we need a generic %posttrans warning on the ScriptletSnippets page that outlines things to watch out for (Do any of the things your installing get used in other scriptlets? Do they register services for other applications?) If the package falls under one of those problems, they should substitute %post for %posttrans.

-Toshio