Re: /usr/etc and /usr/local/etc?
On Wed, Oct 06, 1999 at 09:20:32PM +1000, Brian May wrote:
> On Wed, Oct 06, 1999 at 03:43:07AM -0700, Steve Bowman wrote:
> > > I think if you are going to use /usr/etc, programs should first check
> > > /etc, in case the system administrator wishes to override the sharable
> > > config file for the given host.
> > This is a good idea for programs that live in /usr/bin or /usr/sbin, but
> > would require program support to check for configs in multiple locations.
> > However, I suggest that programs living in /bin and /sbin MUST have
> > their configs in /etc in case /usr is not available.
> What files would you consider fall into this catagory?
Well, I was speaking hypothetically; however, I just did a quick check
on the 780 packages I have installed as follows (extracted from history):
600 cd /var/lib/dpkg/info
603 egrep "^/bin/|^/sbin/" *.list > /tmp/tmp.pkginfo
605 cd /tmp
607 cut -f1 -d':' tmp.pkginfo | sort -u > /tmp/tmp.pkginfo2
610 sed s/\.list$// tmp.pkginfo2 > tmp.pkginfo3
616 for i in `cat tmp.pkginfo3`; do cat /var/lib/dpkg/info/$i.conffiles; done > tmp.pkginfo4 2>/dev/null
And here's the output file (tmp.pkginfo4):
And then, there's the packages I don't have installed that didn't get
checked. I think there's a few files missing that are built during
installation, by postinst's, or by hand, too, including
/etc/hosts (you or someone already mentioned)
and there may be others since searching for these isn't so easy.
Some of these could probably be shared anyway, such as /etc/login.defs
to establish a common policy across machines or /etc/init.d/halt since
there's no obvious reason why it needs to be customized. In fact,
most of the init.d scripts could probably be shared.... But again,
what if /usr isn't available because, say, the network's down.
BTW, I *like* the idea of moving stuff out of /etc to /usr/etc or
maybe /usr/local/etc. It's not the /etc is too big, it's too messy.
I just think that stuff in /bin and /sbin set an upper bound on what
can be moved without breaking things.
> Brian May <email@example.com>
> To UNSUBSCRIBE, email to firstname.lastname@example.org
> with a subject of "unsubscribe". Trouble? Contact email@example.com
Steve Bowman <firstname.lastname@example.org><email@example.com>
Powered by Debian GNU/Linux <http://www.debian.org>