PB> Redhat puts them in /usr/local/etc, afair. Or possibly /usr/local/share ..
There are no choices. Configuration goes in /etc and /usr/local SHOULD be empty
after installation of Linux system except of 7 empty subdirectories:
bin, games, include, lib, sbin, share, src ...
PB> it was never absolutely clear. And /opt? And where does XF86Config go?
-- cut --
3.4.1 /etc/X11 : Configuration for the X Window System
/etc/X11 is the recommended location for all X11 host-specific
configuration. This directory is necessary to allow local control if
/usr is mounted read only. Files that should be in this directory
include Xconfig (and/or XF86Config) and Xmodmap.
-- cut --
PB> In /etc?
No. See above.
PB> That's where I'd put it, but RH doesn't put it there.
Since FHS says that it's belond to /etc/X11 ...
PB> It's in something like /usr/lib/X11/etc.
No. It's in /etc/X11 as it should be.
PB> And what about /var/X11R6/etc?
There are no such dir.
PB> And then where does one put the lock files? I'm religious about
PB> /var/spool/uucp. But what about /var/locks (or /var/lock)? Redhat
PB> probably puts them in /var/locks/subsys, just to be different.
RedHat put then in /var/lock as it should:
-- cut --
5.5 /var/lock : Lock files
Lock files should be stored within the /var/lock directory structure.
The naming convention which must be used is "LCK.." followed by the base
name of the device. For example, to lock /dev/cua0 the file "LCK..cua0"
would be created.
-- cut --
This is not religion anymore. You have no choice (and this is good thing).
>> in /var/log (see FHS 2.0) and user files could be anywhere where admin will put
PB> There aren't any admins in RH. They're all lusers.
I'm refer on this part of FHS:
-- cut --
Different people prefer to place user accounts in a variety of places.
Therefore, no program should rely on this location. If you want to find
out a user's home directory, you should use the getpwent(3) library
function rather than relying on /etc/passwd because user information may
be stored remotely using systems such as NIS.
-- cut --
>> them. What about init files... You really think that constantly growing list
>> with FEW HUNDREDS distributions (few tens listed at www.linuxhq.com are just
>> beginning of this list!) will help here ? Who will mantain it ? How often
PB> Well, if you were to divide into bsd and sysv flavours, you'd make a
PB> fair approximation. But there really is a problem here. Placements are
PB> not compatible amongst the distributions. RedHat is the principal
PB> offender in my opinion.
Debian with it's perl-based startup system is even worse. Since this is
religion this aspect is not touched in FHS :-((
>> for sure... BTW init scripts problem is annoying one but libc problems is far
PB> I'm still waiting for a solution before trying it :-). I'm happy sitting back
PB> here at libc 5.
And I'm does not have libc 5 installed on my system at all :-))
PB> Wake me when it all works.
*ALL WORKS* ? This will never happens. glibc works more reliable then libc5
just now but you could use your libc5 systems if you wish...
PB> But it means I have plenty of experience at compiling and configuring
PB> applications. I can assure you that I make a standard set of changes in
PB> RH spec filezs, another set of changes in SuSE spec files, another in
PB> debian setups, and so on. The distribution and their libc major is the
PB> only key I need.
This is not a solution at all: take a look on linuxhq and try just count
distributions (including different versions! RedHat 5.x has chkconfig while
4.x does not). And you want to say that all programs must be aware about all
distributions ??? You are on drugs :-((
>> more important form autoconf. And thus difference between GNU/Linux and
>> (hypotetic) BSD/Linux or (real) GNU/Hurd ...
>>
>> PB> GSMFR (god save me from redhat).
>>
>> What's wrong with RedHat ?
PB> Everything I can think of (last tried 5.1 - which still hadn't fixed
PB> bugs in their install present since 4.0, such as not working when you
PB> try and make more than 9 partitions at startup, not reading results from
PB> fdisk, only from disk druid, not letting you change the hostname once
PB> chosen a first time, etc. etc.).
Even with all glitches this is simpliest to use linux install I'm seen...
BTW I'm does not use disk druid and all works fine for me here with fdisk, etc.
Hostname could be changed easily via Control Panel (just click on Network
Configuration), LinuxConf (Config->Networking->Client tasks->Basic host
information->Host name) or via edition of /etc/sysconfig/network, etc. If
you can not drive this is does not mean that you are using broken car -- may
be you just can not drive...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/