[OE-core] [PATCH 06/12] classes/[gnome|gnomebase|mime]: merge meta-oe's enhance gnome related classes
Joshua Lock
josh at linux.intel.com
Tue Nov 8 16:35:34 UTC 2011
On 08/11/11 06:05, Richard Purdie wrote:
> On Mon, 2011-11-07 at 16:10 -0800, Joshua Lock wrote:
>> This patch pulls in the gnome related classes from meta-openembedded which
>> adds extra packaging rules and functionality whilst modularising things
>> so that one can get a subset of the gnome classes functionality without adding
>> all of the extra dependencies.
>>
>> Signed-off-by: Joshua Lock <josh at linux.intel.com>
>> ---
>> meta/classes/gnome-base.bbclass | 15 ++++++++++
>> meta/classes/gnome.bbclass | 19 ++-----------
>> meta/classes/gnomebase.bbclass | 32 ++++++++++++++++++++++
>> meta/classes/mime.bbclass | 56 +++++++++++++++++++++++++++++++++++++++
>> 4 files changed, 106 insertions(+), 16 deletions(-)
>> create mode 100644 meta/classes/gnome-base.bbclass
>> create mode 100644 meta/classes/gnomebase.bbclass
>
> Couldn't we have better names for these? What is the difference betweem
> gnome base and gnomebase?
Oh, whoops - gnome-base is the class I wrote to facilitate the GConf
recipe before realising/recalling that meta-oe probably had something
similar. gnome-base is redundant here. Apologies for the noise.
>> diff --git a/meta/classes/gnome.bbclass b/meta/classes/gnome.bbclass
>> index 3d68b12..0a32a77 100644
>> --- a/meta/classes/gnome.bbclass
>> +++ b/meta/classes/gnome.bbclass
>> @@ -1,17 +1,4 @@
>> -def gnome_verdir(v):
>> - import re
>> - m = re.match("^([0-9]+)\.([0-9]+)", v)
>> - return "%s.%s" % (m.group(1), m.group(2))
>> +inherit gnomebase gtk-icon-cache gconf mime
>>
>> -SECTION ?= "x11/gnome"
>> -SRC_URI = "${GNOME_MIRROR}/${BPN}/${@gnome_verdir("${PV}")}/${BPN}-${PV}.tar.bz2;name=archive"
>> -
>> -DEPENDS += "gnome-common"
>> -
>> -FILES_${PN} += "${datadir}/application-registry \
>> - ${datadir}/mime-info \
>> - ${datadir}/gnome-2.0"
>> -
>> -inherit autotools pkgconfig gconf
>> -
>> -EXTRA_OEMAKE += "GCONF_DISABLE_MAKEFILE_SCHEMA_INSTALL=1"
>> +EXTRA_OECONF += "--enable-introspection=no"
>> +BBCLASSEXTEND += "native"
>
> Do we really need to BBCLASSEXTEND every gnome recipe?
Probably not.
>
>> diff --git a/meta/classes/gnomebase.bbclass b/meta/classes/gnomebase.bbclass
>> new file mode 100644
>> index 0000000..5a332a0
>> --- /dev/null
>> +++ b/meta/classes/gnomebase.bbclass
>> @@ -0,0 +1,32 @@
>> +def gnome_verdir(v):
>> + import re
>> + m = re.match("^([0-9]+)\.([0-9]+)", v)
>> + return "%s.%s" % (m.group(1), m.group(2))
>> +
>> +SECTION ?= "x11/gnome"
>> +SRC_URI = "${GNOME_MIRROR}/${BPN}/${@gnome_verdir("${PV}")}/${BPN}-${PV}.tar.bz2;name=archive"
>> +
>> +DEPENDS += "gnome-common"
>> +
>> +FILES_${PN} += "${datadir}/application-registry \
>> + ${datadir}/mime-info \
>> + ${datadir}/mime/packages \
>> + ${datadir}/mime/application \
>> + ${datadir}/gnome-2.0 \
>> + ${datadir}/polkit* \
>> + ${datadir}/GConf \
>> + ${datadir}/glib-2.0/schemas \
>> +"
>> +
>> +FILES_${PN}-doc += "${datadir}/devhelp"
>> +
>> +inherit autotools pkgconfig
>> +
>> +AUTOTOOLS_STAGE_PKGCONFIG = "1"
>
> That variable is long dead, please don't bring it back :)
*whistles*
>
>> +
>> +do_install_append() {
>> + rm -rf ${D}${localstatedir}/lib/scrollkeeper/*
>> + rm -rf ${D}${localstatedir}/scrollkeeper/*
>> + rm -f ${D}${datadir}/applications/*.cache
>> +}
>> +
>> diff --git a/meta/classes/mime.bbclass b/meta/classes/mime.bbclass
>> new file mode 100644
>> index 0000000..b9cdd7b
>> --- /dev/null
>> +++ b/meta/classes/mime.bbclass
>> @@ -0,0 +1,56 @@
>> +DEPENDS += "shared-mime-info-native shared-mime-info"
>> +
>> +mime_postinst() {
>> +if [ "$1" = configure ]; then
>> + if [ -x ${bindir}/update-mime-database ] ; then
>
> This is wrong, it will use update-mime-database from the build system.
> We should really use which to see if its available from the environment
> and use PATH to resolve it.
Will do.
>
>> + echo "Updating MIME database... this may take a while."
>> + update-mime-database $D${datadir}/mime
>
> This however is using $D correctly making the above error all the more
> bizarre!
>
>> + else
>> + echo "Missing ${bindir}/update-mime-database, update of mime database failed!"
>> + exit 1
>> + fi
>> +fi
>> +}
>> +
>> +mime_postrm() {
>> +if [ "$1" = remove ] || [ "$1" = upgrade ]; then
>> + if [ -x ${bindir}/update-mime-database ] ; then
>
> ditto.
>
>> + echo "Updating MIME database... this may take a while."
>> + update-mime-database $D${datadir}/mime
>> + else
>> + echo "Missing ${bindir}/update-mime-database, update of mime database failed!"
>> + exit 1
>> + fi
>> +fi
>> +}
>> +
>> +python ppopulate_packages_append () {
>> + import os.path, re
>> + packages = bb.data.getVar('PACKAGES', d, 1).split()
>> + pkgdest = bb.data.getVar('PKGDEST', d, 1)
>> +
>> + for pkg in packages:
>> + mime_dir = '%s/%s/usr/share/mime/packages' % (pkgdest, pkg)
>> + mimes = []
>> + mime_re = re.compile(".*\.xml$")
>> + if os.path.exists(mime_dir):
>> + for f in os.listdir(mime_dir):
>> + if mime_re.match(f):
>> + mimes.append(f)
>> + if mimes != []:
>> + bb.note("adding mime postinst and postrm scripts to %s" % pkg)
>> + postinst = bb.data.getVar('pkg_postinst_%s' % pkg, d, 1) or bb.data.getVar('pkg_postinst', d, 1)
>> + if not postinst:
>> + postinst = '#!/bin/sh\n'
>> + postinst += bb.data.getVar('mime_postinst', d, 1)
>> + bb.data.setVar('pkg_postinst_%s' % pkg, postinst, d)
>> + postrm = bb.data.getVar('pkg_postrm_%s' % pkg, d, 1) or bb.data.getVar('pkg_postrm', d, 1)
>> + if not postrm:
>> + postrm = '#!/bin/sh\n'
>> + postrm += bb.data.getVar('mime_postrm', d, 1)
>> + bb.data.setVar('pkg_postrm_%s' % pkg, postrm, d)
>> + bb.note("adding freedesktop-mime-info dependency to %s" % pkg)
>> + rdepends = explode_deps(bb.data.getVar('RDEPENDS_' + pkg, d, 0) or bb.data.getVar('RDEPENDS', d, 0) or "")
>> + rdepends.append("freedesktop-mime-info")
>> + bb.data.setVar('RDEPENDS_' + pkg, " " + " ".join(rdepends), d)
>> +}
>
> We don't have freedesktop-mime-info do we? Shouldn't this also check
> DEPENDS and error out if it wasn't in DEPENDS else rootfs construction
> will fail.
>
Hmm, definitely needs more investigation. I'll spin a v2 with your
comments addressed, thanks for the review.
Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
More information about the Openembedded-core
mailing list