gconf: fix multilib conflict - org.gnome.GConf.service
v2 cover gconf: fix multilib conflict - org.gnome.GConf.service
Changes since v1:
Split org.gnome.GConf.service to ${PN}-service
The following changes since commit ccf5a4d2342c4fd40e4e0b332ea7e34e0bf175d4:
build-appliance-image: Update to dizzy head revision (2014-10-11 08:11:17 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib chonglu/gconf
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=chonglu/gconf
Chong Lu (1):
gconf: fix multilib conflict - org.gnome.GConf.service
meta/recipes-gnome/gnome/gconf_3.2.6.bb | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
Signature · 1 line
1.9.1
PATCH v2 1/1 gconf: fix multilib conflict - org.gnome.GConf.service
The gconfd-2 will be called in org.gnome.GConf.service file and the path of gconfd-2 is ${libexecdir}, this will get following error when multilib exported in the sdk:
error: file /usr/share/dbus-1/services/org.gnome.GConf.service from install of gconf-3.2.6-r0.0.lib32_x86 conflicts with file from package gconf-3.2.6-r0.0.x86_64
Split org.gnome.GConf.service to ${PN}-service, the conflict was fixed.
--- meta/recipes-gnome/gnome/gconf_3.2.6.bb | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)
meta/recipes-gnome/gnome/gconf_3.2.6.bb +4 -1
@@ -48,13 +48,16 @@ do_install_append_class-native() { RDEPENDS_${PN} += "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'dbus-x11', '', d)}" RDEPENDS_${PN}_class-native = "" +PACKAGES =+ "${PN}-service" +RDEPENDS_${PN} += "${PN}-service" + FILES_${PN} += "${libdir}/GConf/* \ ${libdir}/gio/*/*.so \ ${datadir}/polkit* \ - ${datadir}/dbus-1/services/*.service \ ${datadir}/dbus-1/system-services/*.service \ " FILES_${PN}-dbg += "${libdir}/*/*/.debug" FILES_${PN}-dev += "${datadir}/sgml/gconf/gconf-1.0.dtd" +FILES_${PN}-service += "${datadir}/dbus-1/services/*.service" BBCLASSEXTEND = "native"
Signature · 1 line
1.9.1
Quoted 8 lines · Chong Lu
The gconfd-2 will be called in org.gnome.GConf.service file and the path of gconfd-2 is ${libexecdir}, this will get following error when multilib exported in the sdk:
error: file/usr/share/dbus-1/services/org.gnome.GConf.servicefrom install of gconf-3.2.6-r0.0.lib32_x86 conflicts with file from package gconf-3.2.6-r0.0.x86_64Split org.gnome.GConf.service to ${PN}-service, the conflict was fixed.
Why are both ML variants of gconf being installed? Presumably for
libgconf, which needs to have ML variants and is packaged into $PN. $PN also contains the binaries and data files, which are not ML-specific and can only be installed once.
So, gconf should split the daemon/binaries from the libraries. I suggested this back in July as it seems the logical answer, instead of splitting the daemon binary and the service file that defines where the binary is.
Ross
Quoted 14 lines · Ross
Quoted 8 lines · Chong Lu
The gconfd-2 will be called in org.gnome.GConf.service file and the path of gconfd-2 is ${libexecdir}, this will get following error when multilib exported in the sdk:
error: file/usr/share/dbus-1/services/org.gnome.GConf.servicefrom install of gconf-3.2.6-r0.0.lib32_x86 conflicts with file from package gconf-3.2.6-r0.0.x86_64Split org.gnome.GConf.service to ${PN}-service, the conflict was fixed.
Why are both ML variants of gconf being installed? Presumably for
libgconf, which needs to have ML variants and is packaged into $PN. $PN also contains the binaries and data files, which are not ML-specific and can only be installed once.
Quoted 6 lines
So, gconf should split the daemon/binaries from the libraries. I suggested this back in July as it seems the logical answer, instead of splitting the daemon binary and the service file that defines where the binary is.
Ross
Hi Ross,
Sorry, I don't understand your solution.
In org.gnome.GConf.service.in file, it has following line:
Exec=@libexecdir@/gconfd-2
And then, in Makefile.am file:
org.gnome.GConf.service: $(srcdir)/org.gnome.GConf.service.in
sed -e 's,[@]libexecdir[@],$(libexecdir),g' \
<$(srcdir)/org.gnome.GConf.service.in Quoted 1 line
org.gnome.GConf.service
In 32bit and 64bit environment, the path of gconfd-2 is different.
So, if we want to install both gconf and lib32-gconf in a image, the error will get as above. In fact, I want to resolve this confliction. Do you have any suggestions?
Best Regards
Chong
Quoted 1 line
Quoted 8 lines · Ross
Quoted 7 lines · Chong Lu
The gconfd-2 will be called in org.gnome.GConf.service file and the path of gconfd-2 is ${libexecdir}, this will get following error when multilib exported in the sdk:
error: file/usr/share/dbus-1/services/org.gnome.GConf.servicefrom install of gconf-3.2.6-r0.0.lib32_x86 conflicts with file from package gconf-3.2.6-r0.0.x86_64
Quoted 4 lines
Quoted 1 line
Split org.gnome.GConf.service to ${PN}-service, the conflict was fixed.
Why are both ML variants of gconf being installed? Presumably for
libgconf, which needs to have ML variants and is packaged into $PN. $PN also contains the binaries and data files, which are not
Hi Ross,
The data file is different between bit-32 and bit-64 environment.
Best Regards
Chong
Quoted 10 lines
ML-specific and can only be installed once.
So, gconf should split the daemon/binaries from the libraries. I suggested this back in July as it seems the logical answer, instead of splitting the daemon binary and the service file that defines where the binary is.
Ross
Quoted 1 line · Chong Lu
The data file is different between bit-32 and bit-64 environment.
And the data file is specific to the daemon, and you only want that installed once. Two gconf daemons will attempt to write the same data file, resulting in corruption.
What I meant is this:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/gconf&id=fac86eb3f86618f109e3797422aae53d9c8d3b30.
Package the client-side libraries into a separate package, so you can have gconfd, libgconf, and lib32-libgconf installed at once. Both client libraries will talk over DBus to the single gconfd binary.
(untested, and needs upgrade path dependencies added)
Ross
Quoted 12 lines · Ross
Quoted 1 line · Chong Lu
The data file is different between bit-32 and bit-64 environment.
And the data file is specific to the daemon, and you only want that installed once. Two gconf daemons will attempt to write the same data file, resulting in corruption.
What I meant is this:
http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=ross/gconf&id=fac86eb3f86618f109e3797422aae53d9c8d3b30.
Package the client-side libraries into a separate package, so you can have gconfd, libgconf, and lib32-libgconf installed at once. Both client libraries will talk over DBus to the single gconfd binary.
Quoted 3 lines
(untested, and needs upgrade path dependencies added)
Ross
Hi Ross,
Thanks for your suggestion, I will send a V3.
Best Regards
Chong
Quoted 2 lines
Quoted 18 lines
Op 15 okt. 2014, om 12:42 heeft Burton, Ross <[email protected]> het volgende geschreven:
Quoted 8 lines · Chong Lu
The gconfd-2 will be called in org.gnome.GConf.service file and the path of gconfd-2 is ${libexecdir}, this will get following error when multilib exported in the sdk:
error: file/usr/share/dbus-1/services/org.gnome.GConf.servicefrom install of gconf-3.2.6-r0.0.lib32_x86 conflicts with file from package gconf-3.2.6-r0.0.x86_64Split org.gnome.GConf.service to ${PN}-service, the conflict was fixed.
Why are both ML variants of gconf being installed? Presumably for
libgconf, which needs to have ML variants and is packaged into $PN. $PN also contains the binaries and data files, which are not ML-specific and can only be installed once.
Quoted 4 lines
So, gconf should split the daemon/binaries from the libraries. I suggested this back in July as it seems the logical answer, instead of splitting the daemon binary and the service file that defines where the binary is.
Keep in mind that both solutions mentioned above will make it virtually impossible to keep a working upgrade path.
regards,
Koen