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

[Stefan Schmidt]

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?

regards
Stefan Schmidt