[OE-core] [PATCH 3/3] systemd: split modules into packages

Bottazzini, Bruno bruno.bottazzini at intel.com
Fri Mar 6 14:03:31 UTC 2015


On Sex, 2015-03-06 at 09:23 +0100, Anders Darander wrote:
> * Bottazzini, Bruno <bruno.bottazzini at intel.com> [150305 17:15]:
> 
> > On Qui, 2015-03-05 at 15:28 +0100, Anders Darander wrote:
> 
> > > Just a quick question before I look into the patch in more detail.
> 
> > > Is the new setting of PACKAGECONFIG consistent with how systemd was
> > > built previously? I guess it is.
> 
> > Hi Anders,
> 
> > it is consistent with how systemd was built previously. If you apply the
> > patch and bitbake it. Systemd will be built and shipped normally.
> 
> > But now it will give some options on how to customize it by excluding
> > packages you don't want to be with systemd.
> 
> Nice, I'm really liking this! That's something I've planned on doing
> myself for a while.
> 
> > > Another comment, you should remove the dependcies that gets added using
> > > PACKAGECONFIG from DEPENDS, e.g. acl etc. (Or are they required
> > > nevertheless?)
> 
> > You mean I should do the following ?
> > - PACKAGECONFIG[acl] = "--enable-acl,--disable-acl,acl"
> > + PACKAGECONFIG[acl] = "--enable-acl,--disable-acl"
> 
> No, I  meant to remove them from the long 
> DEPENDS = "kmod docbook-sgml-dtd-4.1-native intltool-native gperf-native acl readline dbus libcap libcgroup glib-2.0 qemu-native util-linux"
> line. (Unless I overlooked that part in your patch?)
> 
> > If I get what you said correctly, yes they are required. 
> 
> What I meant, was thas unless e.g. acl is required even when building
> with --disable-acl, it's better to add the acl dependency in the
> PACKAGECONFIG like you to. Though, at the same time, remove acl from the
> long DEPENDS-line. (As otherwise we'll build acl anyway).

Anders,

You are right. 

It is not needed to specify the libs on depends. 

I have removed it and as soon as we review the whole patch I will send a
new version with this corrected

Best Regards,
Bruno Bottazzini
> 
> Cheers,
> Anders
> 





More information about the Openembedded-core mailing list