Re: [RFC] systemd units packaging

[Mark Hatle <mark.hatle@windriver.com>]

On 5/6/11 8:39 AM, Koen Kooi wrote:
> Hi,
> 
> The past few days I have gotten systemd to work in OE.dev and I have some questions on how to do in the oe-core universe. First some background:
> 
> Systemd is a /sbin/init replacement using ideas from apples launchd like socket activation. Startup scripts are replaced by .ini like files:

I really want to start experimenting with systemd inside of oe-core.  Can we use
something like the distro flags we had briefly talked about in the TSC meetings
to control which init system is used?

Also a somewhat related question, does this belong in meta-oe or oe-core...
(This might be a good example in meta-oe of extending items within oe-core,
besides being a good place to experiment and prove out the functionality before
it goes into oe-core.)

...

> Now onto my issues:
> 
> packaging:
> In OE .dev I added FILES_${PN} += "${base_libdir}/systemd" to
> udev, dbus, rsyslog and avahi. This means we end up with both sysV script
> and systemd units. What I would like to have is ${PN}-sysvinit and 
> ${PN}-systemd and the image recipe can choose which init systems gets used.
> Is something like that possible? Are there better ways? Note that systemd
> support sysV initscripts as well, but it needs some care with naming. As I
> understand it, if a unit is found with the same name as a sysV script, only
> the unit will get used. A rootfs postprocess command that deletes /etc/init.d
> won't work, since itwill come back when upgrading the packages.>

This is where I think the distro flags could be useful..

The question is what is the best way to control the initscript files.  Should
they be bundled in with the base FILES_${PN}, and then at build-time it's
selected which type of initscript/configuration is enabled -- or should we add a
runtime requirement of ${PN}-init, and provide two alternative ways of
satisfying this.. one sysvinit and one systemd.. (both with appropriate run-time
dependencies)... of course that leads to rootfs construction issues, how does it
know which to select..  <thinking outloud a bit on this>

> building:
> At the moment systemd enabled software installs the units regardless or 
> config options. What should be do with software that has an option for that?
> And what if we need to patch the units files in? The initsystem is a choice
> at the image level, so artificially limiting it to a distro choice is not a
> good idea.

I think we need to define what the distro flags/choices end up meaning.  And if
we want the policy to be image generation time or distribution build-time.
While it would be possible to build a distro both ways, and determine strategy
at image creation time, the complexities noted above may help make a decision.

> sharing:
> The Arch people have a github with their custom units:
> https://github.com/falconindy/systemd-arch-units/ Do we use those? Do we use
> fedora ones https://bugzilla.redhat.com/show_bug.cgi?id=697698 ? People on
> #systemd are talking about a shared repo on fd.o, but nothing tangible yet.

We've got a few people starting to look into PAM.  I think it's somewhat similar
in that there are different ways things can be patches and configured -- we just
have to find a strategy and determine whats best.  If we don't have a systemd
lead within OE, then the best approach is likely to pick a distro that is close
enough to our needs to be used as a starting point.  (For something like PAM,
that is likely Fedora... while for systemd, Arch might be a good choice.. but I
don't know for sure.)

I'm definitely for re-use, but it'd be nice to have someone to champion this and
help define and describe policies.

> And related to this: how do I get the "installed but not packaged" output
> back? The bitbake logging changes are hiding it now, which is
> counterproductive.

Looks like this may have been a bit too aggressive of filtering.  IMHO this
should be a warning not "info" which is filter out.

--Mark

> 
> So, what are your thoughts on all this?
> 
> regards,
> 
> Koen
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core