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

[Bottazzini, Bruno]

Hello Randy,

On Sex, 2015-02-06 at 10:45 -0800, Randy Witt wrote:
> On 02/04/2015 09:04 AM, Bruno Bottazzini wrote:
> > It wil be able to choose what systemd module to be installed.
> > The final result may get smaller, if the user wanted to.
> > By default it will install the whole systemd which may be big.
> > ---
> >   meta/recipes-core/systemd/systemd_218.bb | 1059 ++++++++++++++++++++++++++----
> >   1 file changed, 914 insertions(+), 145 deletions(-)
> 
> This patch will push a lot of maintenance work onto the Yocto systemd maintainer 
> every time there is an upgrade. It's also easy to miss dependencies because of 
> the inter-dependencies that can exist between services.

This is not a problem, we can give this maintenance.

> 
> For items such as systemd-cgls and the tools, a change like this would be 
> maintainable since those items are self-contained. But yanking out the services 
> into separate packages means the maintainer will have to inspect them on each 
> upgrade to make sure they still work.
> 
> Would it be sufficient to use PACKAGECONFIG for each of the items that can be 
> disabled via configure? That way the granularity configuration is done by the 
> systemd maintainers rather than the Yocto maintainer.

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 problem is understanding that although systemd is a single repository 
it contains multiple services and daemons in it that can run even without the 
core PID1, udev or the many helpers used to configure the system such as resolved, 
timedated, localed... 

All of these components are runtime independent, we can install or remove them and 
they should not create problems.

Even Ubuntu is shipping with some of these daemons even if systemd is not used (yet).
If they were different GIT repos then it would be clear that they are separate daemons, 
but as they are all in a single repository people can make a confusion about it.

I see that in the master branch it has already the version 219.

I will make a split packages for the newest version that was just released.

Best Regards,

Bruno Bottazzini

> 
> 
>