[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Question about Facility names



On 22 Nov 2000, Chmouel Boudjnah wrote:

> Date: 22 Nov 2000 06:04:08 -0800
> From: Chmouel Boudjnah <chmouel@mandrakesoft.com>
> To: Theodore Y. Ts'o <tytso@MIT.EDU>
> Cc: Lenz Grimmer <grimmer@suse.de>, lsb-spec@lists.linuxbase.org
> Subject: Re: Question about Facility names
> Resent-Date: Wed, 22 Nov 2000 15:04:34 +0100
> Resent-From: lsb-spec@lists.linuxbase.org
> 
> "Theodore Y. Ts'o" <tytso@MIT.EDU> writes:
> 
> > There's actually another way these dependencies can be used, and
> > happily, either Richard Gooch had the same idea I had, or he read the
> > LSB spec and decided to implement it (don't know which).  Anyway, a
> > Debian developer recently pointed me at this:
> 
> i do not like too much that, what does this bring more (except: back
> compat issue) ? Dependencies ? as acox say it could be in the files
> himself. I guess it could be doable in the current sysv scheme. The
> main rant of Richard for the current Sysv scheme is :
i do not like it too mutch, because dependencies are easy to inser inside
of sysV init.
i would say that basically, we could think to two aor three susV script to
be linked with numbers,
those script could invoce the other scripts  for dependencies. but the
point would be how to determine the full dependencies stuff, since they
could vary
in front of needs and configurations.
So  the traditional sysV way is not so bad, if we can rationalize it, (but
not to mutch :) )

> 
> --=-=-=
> The problem with all this, if it isn't obvious already, is that it's
> complex. The directories of symlinks make it difficult to see what is
> being run and how all the pieces fit together. If that doesn't
> convince you, consider the number of words required to describe this
> scheme. Note how the BSD-style scheme is much easier to describe (and
> by extension, understand).
> --=-=-=
bsd scheme is clean, easy and wonderfull, i agree. but sysV scheme is more
flexible.
we should reduce the number of scripts, makeing the dependencies stuff
inside of them.
I think, for example to a rpc script, that sets nisdomainname and runs
ypbind (and/or ypserv), if 
/etc/defaultdomain is present, starts nfsd and mountd is /etc/export is
not empty, execs mount -a -tnfs id /etc/fstab has those lines, start amd
or automountd if the maps are presents.
that should be done not inside of just one script, that would be
difficoult to read for many, but executing other scripts that are not
directly linked. but rpc script should be linked, of course.

and please, let's keep /etc/rc.d/rc.local, that is so usefull!!

> 
> i do no understand what the problem if we use tools like
> chkconfig(8)...

try chkconfig --list on a red hat and see what comes out, the list is too
long. It is normal, there is a prolification of applications and related
sysV scripts. 
But try chkconf on Irix, or the first chkconfig shell script for linux (i
am still using this sysV init scheme at home), (1995), the list is short
and easy to administer.

to rationalize is not the same as to make a revolution, and it is usually
mutch more usefull.

Luigi Genoni






Reply to: