On 04/09/2019 02:15, DJ Lucas via blfs-dev wrote: > > > On 9/3/2019 2:58 PM, Pierre Labastie via blfs-dev wrote: >> On 03/09/2019 20:21, DJ Lucas via blfs-dev wrote: >> Actually, this is very easy to break systemd into individual components if >> you >> accept to have a systemd daemon as PID 1. > I don't. I consider this _the_ design flaw in systemd. I actually like most of > the individual components. I even have grown to like the journal which I am > now forced to do without. Maybe there was a its inception, but I can't (today) > see a technical reason for the current library grouping - at least not one > that is inseparable as evidenced by how clean it has been to separate the > needed components in eudev and elogind, and now localed - note that I did not > say _easy_, but it really should've been, had it been a design goal of the > project from the beginning (as was stated over and over again). There would be > no purpose for eudev and elogind and it might have stopped some of the > complaints in the beginning (and even a majority that linger today).
Totally agreed, now that I have put my hands on (a small part) of it. The code (in this part at least) is well written: there are not many comments, as Jean-Marc has said, but function names are explicit, so that the code is easy to follow, and when it is not, there are comments. Also, I like the coupling of daemons and their controls (xxxd and xxxctl), which (after getting used to it) makes it easy to administrate things. >> There are a lot of places where this >> daemon is accessed through dbus (I had to remove a couple of such calls in >> localed, and elogind has to do much more to get rid of them, because just >> removing them removes too much functionality). So I think any request to have >> standalone daemons is doomed to failure... > Anyway, on first glance, it looks great. I've done enough fresh raspbian to > pretend it is UK without getting too lost. :-) I'd be a bit happier if > somebody who actually needs this would be able to test as well, however. If > not, I'll get a different keyboard. >> >> BTW, I haven't asked explicitly, but would it be possible that somebody else >> test this patch? >> > I do think it should be split it into it's own package, or at least, make it > build standalone. IOW, get the needed libsystemd parts imported back into > libelogind and change from local includes to system includes (can just ifdef > the includes to avoid extending meson), but we should try to avoid another > reciprocal dependency if possible. May be a bit of work, I can do that part if > you like, but it should be doable. > Hmmm, seems doable. I've opened an issue at elogind, waiting for answer. I'm not even sure libelogind would have anything to be imported: it provides only the sd_something functions, not the utility functions such as those in string-utils, etc. So maybe make an elogind-utils library from those, to avoid recompile? Or recompile, that's not so long anyway. ierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
