Re: [htdig] Linux Standard Base (was Red Hat 7.0 RPMS?)

Subject: Re: [htdig] Linux Standard Base (was Red Hat 7.0 RPMS?)
From: Gilles Detillieux (
Date: Wed Oct 11 2000 - 08:55:29 PDT

Re: putting everything but the kitchen sink in /var...

> > At 11:02 AM +0200 10/11/00, Charles Nepote wrote:
> > >It is recommanded by the Linux Standard Base.
> > >The subject is important, see :
> > >
> > >(is broken today but should work)

A whois search on that domain says "Record expires on 22-Aug-2000."
I guess they haven't been paying their bills.

> > >
> > >
> > >(look at the signature at the end of the page)

What, you mean the quote from Yogi Berra?

The two URLs above that worked didn't give me any indication of what
should or should not go into /var. I guess I'll have to wait for the
LSB's site to come up again before I can see what the standard really
says. However, I tend to be a bit skeptical about designs by committee.
I think standards are a necessary thing, but standards committees do
tend to make some bad decisions at times (e.g. POSIX's choice of some
ambiguous/misleading error codes for some system calls).

According to Bill Carlson:
> On Wed, 11 Oct 2000, Geoff Hutchison wrote:
> > At 11:02 AM +0200 10/11/00, Charles Nepote wrote:
> > >Why not produce ht://Dig compatible with Linux Standard Base (all major
> > >distributions are joining it : Redhat, Debian, Mandrake, Suse, Caldera
> > >and so on) ?
> > >May be for 3.2.0 ?
> >
> > Perhaps. But the world does not revolve around Linux. We try to make
> > everything as portable as possible and that includes many different
> > OSes, e.g. xBSD, Linux, Solaris, IRIX, Digital Unix/Tru64, ...
> >
> > So while it will always be easy to specify installation paths during
> > configuration, I don't know that I'm going to point just towards the
> > Linux filesystem standard. If parts of it make enough sense to adopt,
> > then we'll do that. But only keeping in mind the filesystems used by
> > other systems.
> Hmmm, my Sparc Solaris machine doesn't conform to the LSB. Why should an
> application that is targeted towards multiple platforms conform to the
> standard for a few of those targets? Geoff is right on the money, as
> usual.
> IMO, this kind of customization should be left to the distribution
> producers such as RedHat and others. ht://Dig certainly provides all the
> needed configuration options "out of the source".

I agree. A software package intended for various flavours of Unix/Linux/
POSIX/other shouldn't tie itself too closely to any one standards, but
should be flexible enough to easily conform to various standards. It's
up to the individual distributions to mold packages to whichever standard
they choose to follow.

I made the .spec file follow a standard that closely matched what Red Hat
was doing in 4.x-6.x, which I thought was supposed to be close to LSB.
If Red Hat now chooses to follow some of the more dubious decisions of
the LSB, then the .spec file should probably follow suit, especially if
other RPM-based distributions are doing likewise. That doesn't mean
that all of ht://Dig's Makefile should also follow suit in the main

Take a look at the RPM .spec files for any number of GNU packages, and
you'll see that the RPMs configure the packages to a different set of
default paths than their Makefiles normally use. Why should ht://Dig
be any different? The important thing is that its configure utility
and Makefiles support configurable paths and the concept of a BuildRoot,
as any flexible package should. 3.2.0 has made some improvements as
far as its configurable paths, and I didn't let the broken BuildRoot
support stand very long in the development code.

Gilles R. Detillieux              E-mail: <>
Spinal Cord Research Centre       WWW:
Dept. Physiology, U. of Manitoba  Phone:  (204)789-3766
Winnipeg, MB  R3E 3J7  (Canada)   Fax:    (204)789-3930

------------------------------------ To unsubscribe from the htdig mailing list, send a message to You will receive a message to confirm this. List archives: <> FAQ: <>

This archive was generated by hypermail 2b28 : Wed Oct 11 2000 - 09:00:04 PDT