Richard Purdie <[email protected]> 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 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
