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 > > > -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
