On Wed, May 29, 2019 at 12:31 AM Adrian Bunk <[email protected]> wrote: > On Tue, May 28, 2019 at 04:10:45PM -0700, Andre McCurdy wrote: > > On Sat, May 25, 2019 at 12:25 AM Adrian Bunk <[email protected]> wrote: > >... > > > Supporting musl is a real pain across the board, > > > with new issues all the time. > > > > There are always new issues and bugs to be solved in OE as a > > consequence of trying to keep all packages up to date. Whether the > > issues arising from musl are a real pain or a fun new set of problems > > to solve is mostly a matter of perspective. > > Usually someone submits a change, and later gets notified that the > change was dropped from master-next due to a musl issue. > > That's not fun.
Maybe that happens sometimes but I'm not sure that's the "usual" case. Patches to OE get dropped or ignored for many reasons. If your patch gets as far as master-next and then gets dropped with some feedback it's already done better than many others :-) If you're going to contribute to OE you need to listen to the feedback... and be a little persistent! > And all these compile errors with musl due to header order are a real WTF, > every other library (not limited to C libraries) is now doing headers > properly so that any order works. No fun in supporting a broken design. The musl header ordering issues (the potential for duplication of definitions between low level kernel headers and libc headers) is specific to C libraries. It's actually a perfect example of a problem created by a hard line stance from upstream musl which could be completely solved by a small pragmatic patch applied by OE. > > > For really tiny systems you need both a tiny C library and a tiny init> > > > system, so not properly supporting the combination of both forces users > > > to use alternative options instead of OE. > > > > > > Which minimizes the benefits gained by the pains of supporting musl. > > > > A modern tiny init system would be nice to have, but it's not > > essential or fair to say that musl is useless without one. Many > > projects, especially tiny ones, manage fine with init scripts and > > custom process management. > > I was not asking for "modern". > > If init scripts are not default and CI tested with musl, > then init scripts will soon become a broken part of OE. By that definition (ie anything which is not CI tested is broken) then most of OE is broken. CI testing covers a very narrow set of configurations and if you configure for a real world project you're likely to stray away from them. A few releases back, openssh didn't work for Thumb2 targets because of a conflict between binutils and openssl but wasn't caught by CI testing because (at the time) CI testing was ARMv5 only. In OE 2.7, sqlite3 is broken for big-endian ARM targets (which aren't part of the CI testing). There are many other examples. If you plan to use OE in a real product you'd better plan to do your own CI testing and bug fixing. For many (most?) users that's perfectly acceptable - it's far better to have functionality in OE which is basically sound but may need some tweaks than to strip out everything which hasn't been CI tested. > >... > > A few pragmatic patches applied by OE would go a long way to bridging > > the conflicting goals of the two upstream projects. It's basically the > > approach we've taken already - the question is just one of improving > > the patches we already have (and maybe patching musl to add missing > > functionality instead of only trying to patch systemd to not depend on > > it). > > I already tried patching musl in OE. > The change got reverted. > > There are people who think that OE-specific patches to musl are not > acceptable, and that it is better to force everyone in OE to patch > individual packages all the time instead of adding a not upstreamable > patch to musl. Yes, I saw that. The rules on what is and what is not acceptable in OE are not particularly well defined (and then not consistently applied). It's just the way it is... -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
