[oe] [PATCH 1/4] lvm2: rebase all recipes on a global lvm2.inc recipe

[Simon Busch]

On 28.07.2010 15:44, Stefan Schmidt wrote:
> Hello.
> 
> On Mon, 2010-07-26 at 21:58, Simon Busch wrote:
>> On 26.07.2010 09:46, Stefan Schmidt wrote:
>>> Hello.
>>>
>>> On Tue, 2010-07-20 at 20:44, Simon Busch wrote:
>>>> This rebases all specific versions of lvm2 on a global recipe lvm2.inc which defines the
>>>> common parameters for building lvm2. Staging is overwritten as we don't need any of the
>>>> executables or manpages the build of lvm2 produces for any related builds.
>>>>
>>>> Signed-off-by: Simon Busch <morphis at gravedo.de>
>>>
>>> Looks good. Two comments below.
>>
>> Thank you for commenting this patches!
>>
>>>
>>>> diff --git a/recipes/lvm2/lvm2.inc b/recipes/lvm2/lvm2.inc
>>>> new file mode 100644
>>>> index 0000000..a7e37b5
>>>> --- /dev/null
>>>> +++ b/recipes/lvm2/lvm2.inc
>>>> @@ -0,0 +1,20 @@
>>>> +SECTION = "utils"
>>>> +DESCRIPTION = "LVM2 is a set of utilities to manage logical volumes in Linux."
>>>> +LICENSE = "GPL"
>>>> +DEPENDS = "device-mapper"
>>>> +INC_PR = "r2"
>>>> +
>>>> +S = "${WORKDIR}/LVM2.${PV}"
>>>> +SRC_URI = "ftp://sources.redhat.com/pub/lvm2/old/LVM2.${PV}.tgz \
>>>> +           file://crosscompile_fix.patch"
>>>> +
>>>> +# Unset user/group to unbreak install.
>>>> +EXTRA_OECONF = "--with-user= --with-group= --disable-o_direct"
>>>> +EXTRA_OECONF_arm = "--with-user= --with-group= --disable-o_direct"
>>>
>>> I can see that you just merged this in from an already existing recipe, but do
>>> we know why we have an overrirde for ARM here which changes nothing? Looks bogus
>>> to me.
>>
>> Hm, you are right. I checked it with recompiling without the
>> EXTRA_OECONF_arm statement. It works fine. Is it ok if I supply an extra
>> patch removing this statement or should I rework this patch?
> 
> Both is fine with me.
> 
>>>> +inherit autotools
>>>> +
>>>> +# We don't need to stage anything (the executables are no needed at build time by any
>>>> +# other recipe)
>>>> +do_stage() {
>>>> +}
>>>
>>> While we don't need the executables the don't hurd either IMHO. Can we get rid
>>> of this?
>>>
>>
>> The problem was, that the executables and manpages where installed into
>> the staging dir and never removed, when the packages was clean ur
>> purged. So I added the empty do_stage block to avoid stage of anything
>> from this package as we don't need them anyway.
> 
> Hm, this smells like a bug somewhere else. Did the staged binaries bring in
> other problems or could they get staged until we find out why they are not
> removed?

Staging this binaries let the recompile of the same package fail as it
tries to install the binaries + man pages again.
Any hints where the bug could be? Within the staging logic?

regards,
morphis