On Fri, Mar 27, 2015 at 2:09 PM, Bottazzini, Bruno <[email protected]> wrote: > On Sex, 2015-03-27 at 15:57 +0100, Anders Darander wrote: >> * Bottazzini, Bruno <[email protected]> [150326 14:40]: >> >> > On Qui, 2015-03-26 at 08:56 -0300, Otavio Salvador wrote: >> > > On Thu, Mar 26, 2015 at 5:29 AM, Anders Darander <[email protected]> >> > > wrote: >> > > > * Bruno Bottazzini <[email protected]> [150325 22:50]: >> >> > > >> if one wants to launch a simple deamon, most modules are not >> > > >> required. >> > > >> He will be able to save space and exclude unwanted packages >> > > >> from the final image. >> >> > > > I like this, though I've got a few questions that I just noticed. >> >> > > >> -PACKAGECONFIG ??= "xz ldconfig \ >> > > >> +PACKAGECONFIG ??= " \ >> > > >> + gcrypt \ >> > > >> + kmod \ >> > > >> + ldconfig \ >> > > >> + ${@bb.utils.contains('DISTRO_FEATURES', 'blkid', >> > > >> 'blkid', '', d)} \ >> > > >> + ${@bb.utils.contains('DISTRO_FEATURES', 'efi', >> > > >> 'efi', '', d)} \ >> > > >> + ${@bb.utils.contains('DISTRO_FEATURES', 'lz4', >> > > >> 'lz4', '', d)} \ >> > > >> + ${@bb.utils.contains('DISTRO_FEATURES', 'xz', >> > > >> 'xz', '', d)} \ >> > > >> + ${@bb.utils.contains('DISTRO_FEATURES', 'libidn', >> > > >> 'libidn', '', d)} \ >> > > >> + ${@bb.utils.contains('DISTRO_FEATURES', 'acl', >> > > >> 'acl', '', d)} \ >> > > >> ${@bb.utils.contains('DISTRO_FEATURES', 'pam', >> > > >> 'pam', '', d)} \ >> > > >> ${@bb.utils.contains('DISTRO_FEATURES', 'x11', >> > > >> 'xkbcommon', '', d)}" >> >> > > > It might be worth noting that xz has gone from being explicitly >> > > > enabled, >> > > > to depend on a DISTRO_FEATURES. >> >> > > Agreed and we shouldn't explode the number of possible dsitro >> > > features. I'd also prefer if xz were kept enable by default so we >> > > don't make a behavior change under the hood. >> >> > > ... >> > > >> PACKAGECONFIG[resolved] = "--enable-resolved,--disable-resolved" >> > > >> -PACKAGECONFIG[networkd] = "--enable-networkd,--disable-networkd" >> >> > > > Why do you remove networkd as a PACKAGECONFIG? >> >> > > If there is a real reason for this, it must be recorded in commit log as >> > > well. >> >> > Guys, if you continue this patch you will see that networkd will always >> > be enabled. Systemd will always configure/make it however, the package >> > will not be installed if the user wants to. >> >> > With PACKAGECONFIG, we may not get everything "for free" as some data >> > files will be installed regardless as well as some components from >> > systemd cannot be disabled by their build system but we can run without >> > them, for instance we can run without journald. >> >> The advantage of also keeping the PACKAGECONFIG for e.g. networkd (and >> as much other things as possible) is that we're also reducing the build >> time and size. Sure, it might not be by much, but all small bits are >> valuable. >> > > You are right! Maybe we should mix them ? > > e.g. if PACKAGECONFIG networkd is disabled then the package > systemd-services-networkd will not be included. > > What do you think?
You can add the files conditionally so these empty packages won't be generated. -- Otavio Salvador O.S. Systems http://www.ossystems.com.br http://code.ossystems.com.br Mobile: +55 (53) 9981-7854 Mobile: +1 (347) 903-9750 -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
