On Wed, Nov 9, 2016 at 8:30 AM, Mike Gilbert <flop...@gentoo.org> wrote: > On Wed, Nov 9, 2016 at 2:11 AM, Zac Medico <zmed...@gentoo.org> wrote: >> On 11/08/2016 10:44 PM, Daniel Campbell wrote: >>> On 11/08/2016 05:02 PM, Rich Freeman wrote: >>>> On Tue, Nov 8, 2016 at 7:54 PM, Patrick McLean <chutz...@gentoo.org> wrote: >>>>> On Tue, 8 Nov 2016 17:41:02 -0600 >>>>> William Hubbs <willi...@gentoo.org> wrote: >>>>>> >>>>>> The plan, once the first release is out, is to rewrite this utility >>>>>> in a better language. I'm considering C, but if I am comfortable by >>>>>> that time in Go or Rust, I may use one of them. >>>>>> >>>>> >>>>> For a low-level utility that is likely going to be in the default >>>>> @system set, please use C. Adding dependencies on the go or rust >>>>> compilers for this is not very nice. >>>>> >>>> >>>> Assuming I'm looking at the right sources, the actual systemd >>>> implementation is only 2342 lines of C. Glancing at the includes, I'm >>>> not convinced it even requires systemd to run. >>>> >>>> You might want to take a look at either just creating a split ebuild, >>>> or tweaking it to work standalone if necessary. >>>> >>> Is that including any headers and/or libraries shared by the systemd >>> umbrella? >>> >> >> It has a huge list of includes for internal libraries, from acl-util.h >> to util.h: >> >> https://github.com/systemd/systemd/blob/master/src/tmpfiles/tmpfiles.c > > Also, it is linked against libsystemd-shared.so, which is a 2.1 M blob > on my system. For comparison, libc-2.23.so is 1.7 M. >
My understanding is that this is a once-and-done executable, not a daemon. I won't debate that it probably could be refactored or redone in a smaller overall package. However, the only real cost to it being large is disk space use, a miniscule amount of additional load time (we are talking about an rc solution coded in bash, which has tons of load time penalties), and a few MB or RAM during the short time that it is running. Don't get me wrong. I don't have a problem if somebody wants to take the time to basically rewrite it. But, you're probably going to spend a lot of time chasing edge cases with compatibility with an upstream moving target. I'm sure a lot of the tmpfiles.d features are rarely used, but do you really want to end up hosting debates over whether you really need btrfs subvolume support, POSIX ACL support, xattr support, age-checking and cleanup, support for machine IDs, and so on? In any case, my goal was to toss the option out there, either as a short-term or long-term solution. You have a working implementation that probably could get the job done with minimal effort to adapt it, and it is the same implementation virtually every other distro is using and which is well-maintained upstream. Now, I haven't tried to run it under openrc and there could be some fatal flaw in the suggestion. But, I probably wouldn't be deterred by a couple of libraries. -- Rich
