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

[Stefan Schmidt]

Hello.

On Wed, 2010-07-28 at 19:20, Simon Busch wrote:
> On 28.07.2010 15:44, Stefan Schmidt wrote:
> > 
> > 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?

Good question. Maybe only a  bug in the clean step that it ignores the files
during cleaning. Anybody else an idea?

You could also add a do_install_append which removes the binaries again.

regards
Stefan Schmidt