On Friday 14 March 2008 07:14:23 Rémi Cardona wrote: > - the gnome2 eclass now has a pkg_preinst, if you do multiple > inherits, make sure that gnome2_pkg_preinst is called too. The > _games_eclass_ is one of those.
Maybe worth adding a dummy to the current version of the eclass so that ebuilds can be updated now, instead of suddenly all at once as soon as the new eclass is committed? > - if you use functions from the gnome2-utils.eclass, things may not > work as expected. The _xfce_eclasses_ are on that list. Are you referring to the need to call gnome2_gconf_savelist in pkg_preinst if the ebuild/eclass wants to use the gconf functions? What I said above goes here as well. A couple of things that aren't specific to the new eclass, but I noticed them while checking: > #gnome2_pkg_prerm() { > # gnome2_gconf_uninstall > #} Should this really be commented out? If so, might be worth adding a comment explaining why - it's not clear whether it's disabled because it's broken, or not necessary, or whether ebuilds are expected to call gnome2_gconf_uninstall explicitly if they need to. > # Path to gconftool-2 > GCONFTOOL_BIN=${GCONFTOOL_BIN:="${ROOT}usr/bin/gconftool-2"} > # Path to scrollkeeper-update > SCROLLKEEPER_UPDATE_BIN=${SCROLLKEEPER_UPDATE_BIN:="${ROOT}usr/bin/scrollkeeper-update"} Those aren't going to work with cross-compilation (which isn't well-supported by the current ebuild format, but best to be future-proof), since the executables in ${ROOT} won't be able to run on the build machine. > export GCONF_CONFIG_SOURCE=$(${GCONFTOOL_BIN} --get-default-source) I confess I don't know much about gconf, but that looks as though it'll always return a path in /, not ${ROOT}, so it'll install the schemas in the / database. -- gentoo-dev@lists.gentoo.org mailing list