Re: [meta-oe][PATCH] cryptsetup: Add PACKAGECONFIG options

[Robert Joslyn <robert.joslyn@redrectangle.org>]

On Mon, 2019-07-01 at 23:53 +0000, Peter Kjellerstedt wrote:
> > -----Original Message-----
> > From: Robert Joslyn <robert.joslyn@redrectangle.org>
> > Sent: den 28 juni 2019 05:51
> > To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>; akuster808
> > <akuster808@gmail.com>; openembedded-devel@lists.openembedded.org
> > Subject: Re: [oe] [meta-oe][PATCH] cryptsetup: Add PACKAGECONFIG
> > options
> > 
> > On Thu, 2019-06-27 at 10:56 +0000, Peter Kjellerstedt wrote:
> > > It is no longer possible to build cryptsetup-native after this was
> > > merged.
> > > It now fails with:
> > > 
> > > ERROR: Nothing PROVIDES 'udev-native' (but virtual:native:.../meta-
> > > oe/recipes-crypto/cryptsetup/cryptsetup_2.1.0.bb DEPENDS on or
> > > otherwise
> > > requires it). Close matches:
> > >   fuse-native
> > >   unifdef-native
> > >   db-native
> > > ERROR: Required build target 'cryptsetup-native' has no buildable >
> > > providers.
> > > Missing or unbuildable dependency chain was: ['cryptsetup-native',
> > > 'udev-native']
> > > 
> > > This is with systemd in DISTRO_FEATURES.
> > > 
> > > //Peter
> > 
> > Sorry about that. Is there a reasonable set of options useful for the
> > native build? Any preference for an empty native PACKAGECONFIG or
> > should it be the same as the target (minus udev obviously)?
> 
> I have no idea. I don't even know why cryptsetup-native is being built, 
> all I know is that it can't depend on udev-native. Locally, I have
> fixed  
> it by adding a bbappend with PACKAGECONFIG_remove_class-native =
> "udev", 
> so now it builds again. For meta-oe I would instead suggest to add the 
> udev feature using PACKAGECONFIG_append_class-target = " udev".
> 
> One thing that worries me though is that you stated in the commit
> message 
> that the set of enabled PACKAGECONFIGs should match the default when no 
> enable/disable options are specified. However, this does not seem to
> hold 
> true for udev, as there was no dependency on udev before your change.
> So 
> maybe udev should not be enabled by default for target either?

I looked at it again, and the behavior of --enable-udev and --disable-udev 
is a little different than I thought. --enable-udev is adding a check for
devmapper udev sync support at runtime (it adds a call to
dm_udev_get_sync_support()). So it doesn't need udev at build time for
this, just runtime. libdevmapper has udev support enabled by default for target builds, so that would have been pulling it in before.

I'll send a patch adding udev only for the target build and making it an
RDEPENDS only.

Thanks,
Robert