[OE-core] RFE: make the init manager an image feature (again)

Enrico Scholz enrico.scholz at sigma-chemnitz.de
Sun Feb 17 13:06:36 UTC 2013


Richard Purdie <richard.purdie at linuxfoundation.org> writes:

> meta-oe earned a *horrendous* reputation because of the way systemd was
> implemented there.

Can you point me to the corresponding discussion resp. which aspects of
the meta-oe implementation were criticized?

I can image only two problems with splitted -sysv/-systemd packages:

1. it enlarges the package database

2. there does not exist a good mechanism to select automatically the
   correct subpackage; e.g. so that when somebody makes 'opkg install
   foo', the -sysv subpackage gets installed on sysv systems and the
   -systemd subpackage on systemd systems.  Ditto with rpm and dpkg
   package managers.

   meta-oe implementation defined a default with help of RRECOMMENDS
   which can be overridden at image build time with BAD_RECOMMENDS.


For me, point 1 is negligible because pkg management is disabled for
images where every byte matters.

Point 2 needs some discussion but I am pretty sure that some clean
technical solution can be found.  The most trivial one might be the
moving of -<initsys> packages into an own 'all-<initsys>' architecture
whose package feed is enabled at image build time. This does not scale
well and violates orthogonality of buildsystem somehow, but works now.

Another approach might adding RRECOMMENDS on all supported -<initsys>
packages and let the package manager choose this with the lowest costs.
That's not trivial and requires probably changes in opkg.

Blacklisting packages with a certain, configurable pattern in its name
or (better) rprovides (e.g. implementing BAD_RECOMMENDS in opkg, smart,
...) is another way requiring changes in the package manager.
  

> I believe (as do a number of others) that it has damaged OE's reputation
> and usability and actively hurts new users.

The current oe-core implementation hurts active, long time users.


> It was clear systemd needed to move into the core but also become more
> configurable to work for everyone.

Exactly this configurability was taken away.


> I don't want to remove features, I do want to talk about whether there
> is a better way we can fulfil certain uses cases, particularly with a
> focus on usability.

For me, a good usability of a build system is defined by a small,
orthogonal and powerful set of tools and rules.

Implementing hacks for specific use cases (e.g. magically remove the
busybox or util-linux -> systemd dep for "rescue systems") violates
this and will probably cause bad surprises (e.g. for people who want
'lighttp' in the rescue system and when the hack has not been applied
to this package).


> I'm actually moderately annoyed that throughout the various discussions
> about systemd and how we'd get it into OE-Core nobody actually mentioned
> these specific requirements until very late in the implementation.

That's a general problem with oe release model.  Parts of systemd (in
-core) were changed without adapting the other ones (in -meta).  This
made the whole oe unbuildable for me for one week and I did not saw the
problem with the rescue image hence.


>> Assuming we are able to break the hard dependencies, what is with package
>> scripts which require programs, files or directories from these deps?  Do
>> we need a way to differ between good and bad script failures then?
>
> At the technical level there is little difference from packaging these
> things separately to avoid specific dependencies and explicitly telling
> the package manager to avoid that dependency instead.

see Martin's comment about post/pre scripts


> Equally there are other cases where people do want to break specific
> dependencies so this could help us in that area too.

Dependencies and recommends are good and moving things into subpackages
is *the* way to break them.



Enrico




More information about the Openembedded-core mailing list