Re: RFE: make the init manager an image feature (again)

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Fri, 2013-02-15 at 19:19 +0100, Enrico Scholz wrote:
> it would be nice when the decision to make the init manager a distribution
> feature will be reverted to the old oe-meta mechanism.
> 
> Being a distribution feature means, that packages are created in such a
> way that it is impossible to split off unwanted and heavy weighted
> functionality at image creation time.
> 
> E.g. on most of my systems, I create two kinds of images: a full
> featured, systemd based one and a very minimal rescue system with
> busybox and some filesystem utilities.  With recent systemd packaging
> change, the rescue image size grow up from 5.9 MiB to 27 MiB because
> systemd dependencies are hardcoded in mandatory packages.
> 
> Formerly, systemd dependencies could be avoided by adding the -systemd
> packages to BAD_RECOMMENDATIONS (e.g. due to busybox-syslog ->
> busybox-syslog-systemd rrecommend).
> 
> I am aware that initscripts were always part of the main package.  But
> sysvinit was very lightweighted and the extra space either negligible or
> easy to recover by removing some files in IMAGE_PREPROCESS_COMMAND.
> 
> Hence my recommendation: make the init manager an image feature again
> and create -systemd and -sysv packages with the corresponding scripts.
> OpenEmbedded is still for embedded devices where size matters.
>
> Of course, systemd can be still a distribution feature to enable things
> like socket activation as part of PACKAGE_CONFIG.  But dependencies on
> init system packages should be RRECOMMENDS which can be overridden
> easily at image creation time.

The trouble is that by making it an "image feature", people will expect
*everything* to work properly and to be able to have fully functional
sysvinit and systemd variants of images. We already see this
expectation. Trying to explain to people what the limitations are, what
is expected to work and what isn't will be difficult. I know you
understand this but going forward most people will simply not and I
think it will be a nightmare for usability.

For that reason I'd rather see this done in a different way, for example
blacklisting the problematic systemd dependencies at image generation
time with some kind of stronger BAD_RECOMMENDS code. Yes, this means
there would be some systemd config files lying around but you'd stop the
main bulk of it coming in (and as you said, some small config files
aren't an issue).

Cheers,

Richard