Hi,
Since the wiki doesn't allow useful collaboration on immutable pages, here is my suggestion for the gconf schema installation snippet in the form of a patch.
It tries to emphasize the proper (IMHO) --disable-schemas-install method of disabling schemas installation on the build host vs the prevalent GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL hack (again IMHO)
Regards Yanko
--- ScriptletSnippets 2006-08-20 09:04:41.000000000 +0300 +++ ScriptletSnippets.gconf 2006-08-20 09:29:51.000000000 +0300 @@ -148,6 +148,12 @@
Here's the first part: {{{ +%build +%configure --disable-schemas-install +... +}}} +In the cases where the package doesn't use autotools or doesnt support the --disable-schemas-install configure flag we instuct gconftool to ignore schema installation commands by setting the GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL environment variable +{{{ %install rm -rf $RPM_BUILD_ROOT export GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1
On Sun, 2006-08-20 at 09:45 +0300, Yanko Kaneti wrote:
Hi,
Since the wiki doesn't allow useful collaboration on immutable pages, here is my suggestion for the gconf schema installation snippet in the form of a patch.
PackagingDrafts/ScriptletSnippets is useful for this. Changes can then be voted on and merged to the official, immutable pages.
It tries to emphasize the proper (IMHO) --disable-schemas-install method of disabling schemas installation on the build host vs the prevalent GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL hack (again IMHO)
Could you explain why the configure script option should be considered canonical and the environment variable a hack?
-Toshio
On Sun, 2006-08-20 at 10:19 -0700, Toshio Kuratomi wrote:
On Sun, 2006-08-20 at 09:45 +0300, Yanko Kaneti wrote:
It tries to emphasize the proper (IMHO) --disable-schemas-install method of disabling schemas installation on the build host vs the prevalent GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL hack (again IMHO)
Could you explain why the configure script option should be considered canonical and the environment variable a hack?
Its should be canonical because its part of the AM_GCONF_SOURCE_2 autoconf macro which in turn is used by perhaps 99% of all gconf-using packages out there. Now, some use the macro but don't honor the automake conditional that --disable-schemas-install sets. This IMO should be considered an upstream bug.
As to why using an overly wordy environment variable to negate a specifically invoked action of a tool should be considered a hack? I'll leave that to your good taste. I personally consider the existence of this mechanism a GConf birth defect that's been carried for too long.
On a side-note If there was a more global auto* foo for flagging a staged build/install perhaps we wouldn't need package specific magic like that at all.
Yanko
On Sun, 2006-08-20 at 22:21 +0300, Yanko Kaneti wrote:
On Sun, 2006-08-20 at 10:19 -0700, Toshio Kuratomi wrote:
On Sun, 2006-08-20 at 09:45 +0300, Yanko Kaneti wrote:
It tries to emphasize the proper (IMHO) --disable-schemas-install method of disabling schemas installation on the build host vs the prevalent GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL hack (again IMHO)
Could you explain why the configure script option should be considered canonical and the environment variable a hack?
Its should be canonical because its part of the AM_GCONF_SOURCE_2 autoconf macro which in turn is used by perhaps 99% of all gconf-using packages out there. Now, some use the macro but don't honor the automake conditional that --disable-schemas-install sets. This IMO should be considered an upstream bug.
As to why using an overly wordy environment variable to negate a specifically invoked action of a tool should be considered a hack? I'll leave that to your good taste. I personally consider the existence of this mechanism a GConf birth defect that's been carried for too long.
Thanks! I've started work on integrating that into the Draft for the next ScriptletSnippets page [1]_ and added it to the schedule [2]_. I'd like to take a look at some packages in Extras to make sure that most upstream packages will work with this suggestion and then we'll discuss this on this mailing list or in one of the weekly IRC meetings.
[1]_ http://www.fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets [2]_ http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo
-Toshio
On Wed, 2006-08-23 at 09:54 -0700, Toshio Kuratomi wrote:
I'd like to take a look at some packages in Extras to make sure that most upstream packages will work with this suggestion and then we'll discuss this on this mailing list or in one of the weekly IRC meetings.
[1]_ http://www.fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets [2]_ http://www.fedoraproject.org/wiki/Packaging/GuidelinesTodo
Here is some manually extracted food for thought. ^------^ (it could be quite wrong)
- Packages that can be converted to --disable-schemas-install now -- Core -- bug-buddy compiz control-center desktop-printing devhelp ekiga eog epiphany evince evolution-webcal file-roller gcalctool gconf-editor gedit gnome-applets gnome-bluetooth gnome-games gnome-keyring-manager gnome-media gnome-netstatus gnome-panel gnome-power-manager gnome-screensaver gnome-session gnome-system-monitor gnome-terminal gnome-user-share gnome-utils gnome-vfs2 gnopernicus gok gthumb libgnome metacity nautilus nautilus-cd-burner rhythmbox tomboy totem vino -- Extras -- banshee blam byzanz celestia gnome-applet-music gnome-applet-timer gnome-translate gnumeric gossip gramps liferea mail-notification muine qa-assistant regexxer revelation screem seahorse xchat-gnome
- Packages needing upstream fixes to honor --disable-schemas-install -- Core -- evolution gnome-pilot sound-juicer -- Extras -- buoh contacts firestarter ghex glunarclock gnochm gnome-blog gnotime gstreamer08-plugins gwget monkey-bubble wp_tray
- Other dasher - using gconf but not using AM_GCONF_SOURCE_2 conglomerate - needs upstream fixes for installing the schemas gmpc - doesnt need schema snippets as it doesn't use gconf gnome-applet-netmon - doesnt need schema snippets as it doesn't use gconf
packaging@lists.fedoraproject.org