On 04/09/2019 10:06, Pierre Labastie via blfs-dev wrote: > 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.
Just got an answer from an artix guy. There is a project maintained (well, there has not been any commit since 2012) by gentoo: https://gitweb.gentoo.org/proj/openrc-settingsd.git/ which actually also includes hostnamed and timedated (but no corresponding ctl programs). It seems to depend on openrc, but I am not sure the dependency is too hard, and I think it could be patched to use our own /etc/sysconfig settings... Will have a look, Pierre -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
