Re: [MiNT] some MINTLIB patches here...

[Martin-Eric Racine <q-funk@pp.fishpool.com>]

Hi Guido!

> > >   #define	_PATH_DEFPATH		"/usr/local/bin:/usr/bin:/bin"
> > >   #define	_PATH_DEFPATH_ROOT	"/usr/sbin:/usr/bin:/sbin:/bin"
> > > 
> > >   This is true Linux but MiNT is more oriented towards BSD.  
> > 
> > Except that FHS relocates everything previously found in /usr/etc
> > and /usr/ucb to /usr/sbin and /usr/bin respectively.
> 
> What is FHS?  I don't know the abbreviation.

It is a not-so-recent standard that started on Linux and has spread
to other Unices afterwards.  It defines more precisely what each
filesystem paths is used for and whioch binaries are found where.

The goal is to make location of well-known binaries more predictable
and more consistant from one Unix variety to the other.

Reference:  http://www.pathname.com/fhs/

Beleive me, FHS is a very reasonable standard. It will be a good thing
for MiNT to upgrade to this. ;-)

> Anyway, /usr/ucb should still be included for compatibility reasons.

It _could_ indeed, if desired.  FHS only implies a minimal implementation.
That doesn't mean distributions cannot add other paths, for historical or
compatibility reasons. :)

> If Linux defines these macros we can do it, too, because developers will
> certainly take care of Linux. OK.

That's another good reason to follow FHS recommendations, because
nowadays most of the Unix developments come from the Linux scene.
The closer we are to their practices, the easiest it gets to port
stuff and implement new features.

> > >   The processor field in utsname.h is not supported at all AFAIK
> > 
> > It is. That's why ports on GNU uname command report "unknown" on
> > MiNT, because _we_ haven't supported it...
> 
> No.  GNU uname will report "unknown" if sys/systeminfo.h or
> sysinfo (SI_ARCHITECTURE, ...) is not present, look at the
> sources.

Yes, but the structure of uname is in utsname.h and the last field
(processor) was still undefined.

> A "processor" field neither exists in Linux, nor in HP-SUX nor Solaris.

It does (uname -p), but the way Linux replies to Uname options is twisted.

> > > The KGMD had a very consistent directory structure and it was
> > 
> > I definitely don't agree here.  KGMD is messy.
> 
> Where?

For example, what is the rationale behind /etc hierarchies?
If you answer Configs, then why does /usr/etc have binaries?

In FHS, all commands reside in the /bin (or /usr/bin /usr/local/bin)
while daemons or utilities (eg: fsck, init ...) are in /sbin (or
/usr/sbin /usr/local/sbin).  Isn't this more concise and logical?

> A propos your NMD.  How far are you?  May I ask you not to spend
> too much time on the smtp daemon?  I currently integrate named
> pipes (fifos) into MiNT.  They are a prerequisite for running
> qmail and if I succeed with it, qmail is probably first choice
> for a new MiNT distribution.

Most of what I do, in the process of building NMD, is to recompile
existing stuff to comply with FHS pathnames and sometimes to port
more recent versions of what we already have since KGMD.  That's it.

This is already time-consuming and sometimes infuriating (_LOTS_
of stuff found in KGMD refuses to compile using GCC 2.7.2.3 and 
LIB more recent than 46 - or produces buggy binaries that require
a large stack to correctly operate and fix them - so I have to 
revert to GCC 2.5.8 and my FHS-corrected LIB 46 to compile), so 
I don't spend much time on newer stuff. ;)

> qmail is updated very often, so it's probably more up-to-date.
> I will let you know if I can get qmail to run.

Coolness!

----------------------------------------------------------------
Martin-Eric Racine       http://www.pp.fishpool.com/~q-funk/M-E/
The Atari TT030 Homepage   http://www.megacom.net/~q-funk/TT030/
New MiNT Distribution   http://members.tripod.com/~TT030/nmd.htm
----------------------------------------------------------------