Re: /usr vs. root was: /etc /usr/etc
>>"Vadim" == Vadim Vygonets <firstname.lastname@example.org> writes:
Vadim> On 5 Jul 1997, Manoj Srivastava wrote:
>> I don't think that this proposal is ready for a fiat/vote
>> resolution yet. We would need a little more detail IMHO. Could
>> someone, for example, detail which conf files should be moved to
>> /etc? Is there anyone in this forum that is on the FHS lists?
Vadim> The division goes like this: if the program puts its config
Vadim> files in /usr, they must go into /usr/etc; if the program puts
Vadim> its conffiles on the root partition, they must go to /etc.
So, we decide on placing files dependeing on where the
upstream sources put their files? This does not sound like a sound
technical policy to me. Remember, most authors do not write with
Debian's file system discipline in mind.
>> I think that a major flaw in this proposal is that the division of
>> conf files into machine local and site wide depends on the site it
>> self (is emacs configuration site wide? No, since only the doc guys
>> want to spend time setting up auctexand sgml.
Vadim> You have user's .emacs for it. It must depend on the user, not
Vadim> on the machine one is working on.
No, I have 500 people on the documentation group and we all
use machines XXA to XXZ. I don't want all 500 to continue making
changes as the requirements of the group change. On the other hand,
the 15,000 developers do not want auctex on the system. Not site
wide, but a section of the site. The only solution that worked for us
(make thet secretaries and undergrads) was rdist, not second guessing
the local configuration.
Vadim> This one must be discussed, but see below.
>> Who decides which file is site wide? What happens if the local site
Vadim> Then, there are proposals which are designed for this
Vadim> situation. For site-wide conffiles, many people would like to
Vadim> make it like this: if the conffile is found in /etc, use it;
Vadim> otherwise, look in /usr/etc. Of course, it's only for the
Vadim> conffiles which belong to /usr, i.e., site-wide. It won't work
Vadim> like this for files like /etc/passwd or /etc/hostname. They
Vadim> will always be in /etc.
Why complicate the simple elegance for a partial hack? Unless
there is a clear division of the locations, this will lead to an
unholy mess. Also, I believe this issue came up in the early stages
of the FSSTND (when I used to be on the list), and has been discussed
ad-infinitum, and the consensus was agains the split (correct me if I
remember incorrectly). I have little desire to rehash the issues, but
I will if I must, or if you present compelling technical arguments
agains the current practice.
>> Making the boot smaller when the non-essential config files are
>> less than 1Mb in size is not a good enough reason, seeing that it
>> would entail breaking FSSTND compliance.
Vadim> Many people pointed that we must have a clean solution, and if
Vadim> we find a solution cleaner than one in fsstnd, we should use
Vadim> it. I think we found one.
I have yet to see a technical argument to that effect
(imperative statements don't really count).
>> The proposal is flawed, because it does not solve the problem
>> cleanly either (what if my site has a different idea about which
>> packages have local changes than Debian does? Do I have to change
>> conf files around?)
Vadim> What do you mean? If I understood you right, you mean that
Vadim> your site may have different ideas about which config files are
>> Also, as a sysadmin, I really liked to have the conf files for all
>> machines at a central location, and I used rdist. That allowed me
>> to group machines into categories (DCE client machines, Server
>> machines, file servers, print servers), allowed me the flexibility
>> of distributing the same printcap file to all print clients, while
>> having different fstab files; I could even have a cmmand execited
>> when I updated /etc/aliases.
Vadim> I already explained why this solution is better than rdist.
Vadim> Make the root partition changing as less as possible. IMO
Vadim> having some of the conffiles in /usr/etc is better. Of course
Vadim> you must use rdist sometimes, but not too much.
I think that an inviolate root partition is not as much of a
requirement as ease of management. In fact, *why* should the
root partition be constant, if I can centrally control all my
machines? What does it buy me? If you don't have centralized control
you hae to scramble all over the place, putting in policy hacks like
NO-CHANGE-ROOT-PARTITION and SITE-WIDE-CONFIGURATION-IN-USR. Instead,
please look at professional management systems (I personally prefer
TME) which would be the way to go. I think that distributing the
conffiles just leads to confusion, and hacking the programs to get
the same results we get today.
If you lack the big bucks for TME (as do I), you use
rdist, with none of the (pardon me) bureaucratic policy hacks
All you have offered is an opinion that some files in /usr are
bertter. This comes at the cost of modifying programs to search n
/etc, then in /usr, and at the cost of confusion where a particular
programs conf files may lie (I agree this is not a major drawback,
since there are only two (or three, with /usr/local/etc) locations
proposed.) And using the upstream authours guidelines, when the
programs are rarely designed with Debian's file system discipline in
mind, seems like a poor choice for partitioning.
I think this concludes y input on this issue.
glad not to be maintaining a user system that my old boss tells me
now has 25,000 users, 43 vendors, 6 operating systems, and an average
of 6.458 crises per day ;-)
The makers of fortunes have a second love of money as a creation of
their own, resembling the affection of authors for their poems, or of
parents for their children ... and hence they are very bad company,
for they talk of nothing but the praises of wealth. Plato
Manoj Srivastava <url:mailto:email@example.com>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .