I agree with Stephane. Follow the standards. They were conceived with considerable thought.
bob On Wednesday 09 October 2002 08:38 pm, Stephane Gourichon wrote: > On 9 Oct 2002, Guillaume Cottenceau wrote: > > Yes, though if the flexibility costs so much, > > It doesn't cost that much. > > One hard prerequisite is to think it right. But Mandrake doesn't have to > do this job themselves: that's what the FHS is for. > > Standards make things clear. Following them is not as hard as designing > them. > > > it may become questionable whether we do it or we do other things > > which may be more useful to a larger number of people. I see your > > problem as something valuable but rather a "niche" than something > > really useful to a large number of people. > > Linux is used in a lot of universities, with small or large networks of > client machines. > > Sometimes, a cascaded system exists, where central servers provide > common apps, and local admins can tune local things. /usr exists for > that. The Unix hierarchy has been doing this for ages. Every package > that breaks this is flawed. > > Big Cybercaf�s sometime use this, too. Having /usr mounted via NFS make > it much easier to maintain and secure... if it doesn't break all > packages. > > How can you tell newbie sysadmins that files in /usr are meant to be > frozen, variable files go to /var, when kscd puts its growing stuff > inside /usr ... > > > Besides this, the lack of unattended package upgrade facility for > clusters of machines, and the flakey distribution upgrade that makes the > sysadmins prefer install from scratch instead, currently limit Mandrake > to a lonely desktop machine -- or a collection of lonely desktop > machines, until you roll your own local hack to cope with this. The > solution we have here is our homemade package that installs and > configures a list of things. > > (To my knowledge, MandrakeUpdateRobot didn't make the reliable > unattended daily update we expected, but sorry, I've not tried 9.0 yet, > things might have changed. As for the upgrade, from 8.1 to 8.2 did break > many things when we tried, too many to fix. If things have gone better > with 9.0, tell me.) > > I have other ideas for alternative solutions, but I'll tell in a > different mail.
