[oe] [PATCH 1/1] libbonobo.inc: add libbonobo-bin package

Koen Kooi koen at dominion.thruhere.net
Tue Nov 18 18:32:19 UTC 2014


> Op 18 nov. 2014, om 16:27 heeft Paul Eggleton <paul.eggleton at linux.intel.com> het volgende geschreven:
> 
> Hi Koen,
> 
> On Tuesday 18 November 2014 13:48:15 Koen Kooi wrote:
>> Hongxu Jia schreef op 13-11-14 12:42:
>>> On 11/13/2014 07:02 PM, Koen Kooi wrote: Hongxu Jia schreef op 12-11-14
>>> 
>>> 03:13:
>>>>>> The previous libbonobo package contains perl scripts, while
>>>>>> installing libbonobo, package management detected perl required,
>>>>>> but it actually not needed as lib. So add libbonobo-bin package to
>>>>>> contain these scripts. It refers debian:
>>>>>> https://packages.debian.org/sid/libbonobo2-bin
>>>>>> 
>>>>>> Signed-off-by: Hongxu Jia <hongxu.jia at windriver.com> ---
>>>>>> meta-gnome/recipes-gnome/bonobo/libbonobo.inc | 3 ++- 1 file
>>>>>> changed, 2 insertions(+), 1 deletion(-)
>>>>>> 
>>>>>> diff --git a/meta-gnome/recipes-gnome/bonobo/libbonobo.inc
>>>>>> b/meta-gnome/recipes-gnome/bonobo/libbonobo.inc index
>>>>>> 8b6007e..e0f6168 100644 ---
>>>>>> a/meta-gnome/recipes-gnome/bonobo/libbonobo.inc +++
>>>>>> b/meta-gnome/recipes-gnome/bonobo/libbonobo.inc @@ -5,10 +5,11 @@
>>>>>> LIC_FILES_CHKSUM =
>>>>>> "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \ SECTION =
>>>>>> "x11/gnome/libs" DEPENDS = "glib-2.0 orbit2 intltool-native libxml2
>>>>>> dbus dbus-glib"
>>>>>> 
>>>>>> -inherit gnomebase gtk-doc +inherit gnomebase gtk-doc lib_package
>>>>>> 
>>>>>> ORBIT_IDL_SRC = "${STAGING_BINDIR_NATIVE}/orbit-idl-2"
>>>>>> 
>>>>>> +RDEPENDS_${PN}-bin = "${PN} perl" FILES_${PN} +=
>>>>>> "${libdir}/orbit-2.0/*.so ${libdir}/bonobo/monikers/*.so"
>>>>>> FILES_${PN}-dbg += "${libdir}/bonobo/monikers/.debug \
>>>>>> ${libdir}/bonobo-2.0/samples/.debug ${libdir}/orbit-2.0/.debug"
>>> 
>>> This breaks the upgrade path
>>> 
>>>> I am sorry I do not understand what you mean, do you mean running
>>>> 'smart upgrade' failed?
>> 
>> You are moving files between packages, which makes 'opkg update ; opkg
>> upgrade' fail with conflicts unless you carefully craft RREPLACES/RCONFLICTS
>> or enforce ordering in upgrade order (which isn't currently possible).
> 
> So what would you suggest - never make any packaging changes?

No. I suggest thinking about what you're doing and minimizing the damage. So far the patches I've seen are misguided (recipe==package assumption) or plain weird. And in all cases break upgrade paths. Since arguing the use case seems to fall on deaf ears I can only argue the technical problems with them.

> It's not as if 
> this is the first time we've done this kind of thing...

And people still sound surprised when I say upgrade paths are broken between releases. You yourself told me I should speak up when seeing such patches and so I did.


More information about the Openembedded-devel mailing list