[ On Thursday, March 18, 1999 at 23:05:04 (-0800), John Nemeth wrote: ]
> Subject: Re: CVS commit: src
>
>      diff and patch work wonders here.  As I've said I've had to
> change the files in /etc/init.d many times.  This means that at
> upgrade time I lose.

RCS, or diff&patch, or some other version control tool, can work wonders
anywhere scripts and line-oriented configuration files are concerned,
and that includes the scripts like those in /etc/init.d.

Clearly if you don't want to use change management tools then the more
you hack the more you lose when you try to do a system upgrade.

>  Not to mention the upgrade restoring symbolic
> links in /etc/rc?.d that I've renamed/deleted.  

You're not supposed to use symlinks in /etc/rc?.d -- just hard links to
the actual scripts in ../init.d (which are possible to track in both
directions, unlike symlinks).

I agree that a table driven system is probably better than relying on
filesystem structure to control the order of system startup and
shutdown.  It is much easier to version control a text table than it is
to do the same with a directory tree, at least with the currently
available filesystem.

/etc/rc.conf is the beginnings of a design for a control table, an it's
a zillion times better than the original scheme of just a couple of
hard-coded scripts that do everything.

Hopefully someone doesn't pipe up and suggest a M$-style .INI format for
the control table!  ;-)

> From an upgrade point
> of view, there really is no advantage to /etc/init.d.

It depends on what you're upgrading, and how modular the OS packaging
system is, and how drastic the upgrade is.  (not to mention how well the
original system was implemented and how much hacking you did on the old
version and whether or not you used version control tools and techniques
to track you hacks)

> } Result: if you upgrade, you have to re-do all the local configuration
> } in /etc/rc.conf from scratch.
> 
>      I'm not sure this is true, but even if it is, so what?  It's a
> lot easier to deal with one file, then it is to deal with 20+.

Not necessarily.  It depends on what tools you use and how many hacks
you had to make and in this case how many hacks you were able to
generalize into a form that you could feed to the OS maintainers so that
they were already present in the new version.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>