djb utilities

Stefan Krah sfk1 at
Mon May 5 12:38:05 PDT 2003

* Larry Lawrence <larry at> wrote:
> I'll show a little of my generationism by stating that "rules are meant to
> be flexible", so fair warning, I'm going way out on a limb here.
> I keep having thoughts about letting DJB utilities build "the way the author
> intended".  Of course that means throw FHS to the wind, and send LBS a
> packing (sorry, this does not make me cry, adopting 'rpm' was a big
> mistake).  BTW, some would say I already throw FHS to the wind, but that's a
> different flame war.
> There are a few underlying themes that could be presented through the book.
> First, standards are good, but someone will always challege the standard.
> Second, sometimes the challenger is right.  Third, the user will ultimately
> choose the best solution which then must be incorporated into the standard.
> So the question is this.  Are we doing DJB Utilities a disservice by
> relocating all the files just like every other distrobution AND would
> installing these utilities as the author intended harm any of our current
> packages?

To the first part of the question:

The current BLFS install method doesn't really impact the
/functionality/ of daemontools/ucspi-tcp.

To the second part:

You could install everything as DJB wishes without affecting other

I could imagine the following scenarios:

1. Leave everything as it is


      - FHS compliance (IF that is an advantage)


      - confusion of /etc/service /etc/services for newbies

      - /etc has to be on an writable filesystem

      - /etc/service is not logical for the whole concept

      - more work when adapting existing scripts/howtos

2. Compromise - use /var/service instead of /etc/service


      - FHS compliance

      - /etc can be read-only

      - slightly more logical for the concept than /etc/service


      - more work when adapting existing scripts/howtos

3. Use /service


      - logical concept (IMHO also for newbies), especially when putting
        the real configuration data into /etc and symlinking them to
        /service. My /service directory looks like this:

        dnscache -> /etc/dnscache
        klogd -> /etc/klogd
        leafnode -> /etc/leafnode
        nullidentd -> /etc/nullidentd
        qmail-send -> /var/qmail/supervise/qmail-send
        qmail-smtpd -> /var/qmail/supervise/qmail-smtpd
        sshd -> /etc/sshd
        syslogd -> /etc/syslogd
        tinydns -> /etc/tinydns

      - /service and /etc can be on different filesystems (Obviously
        you wouldn't use the symlinks when you desire a readonly /etc).

      - _slightly_ less work when adapting existing scripts/howtos


      - No FHS compliance

4. Go all the way and use /service, /command, /package and /usr/local


      - no need to adapt existing scripts/howtos

      - easy install commands

      - get familiar with DJBs /package hierarchy


      - No FHS compliance

      - So far DJB only uses the /package hierarchy for daemontools.
        He didn't bother to adapt his other software, so it seems
        a bit overdone to create /command and /package just for

      - IIRC DJB uses /usr/local because the package managers of
        the distributions leave it alone. Since LFS is a custom
        "distribution", /usr/local seems unnecessary

My personal preference is scenario 3, followed by 4 and 2.

Stefan Krah
Unsubscribe: send email to listar at
and put 'unsubscribe blfs-dev' in the subject header of the message

More information about the blfs-dev mailing list