[590] in arla-drinkers
Re: arla 0.21 Oops on Linux 2.2.1
daemon@ATHENA.MIT.EDU (Magnus Ahltorp)
Fri Feb 5 17:13:22 1999
From owner-arla-drinkers@stacken.kth.se Fri Feb 05 22:13:21 1999
Return-Path: <owner-arla-drinkers@stacken.kth.se>
Delivered-To: arla-drinkers-mtg@bloom-picayune.mit.edu
Received: (qmail 16118 invoked from network); 5 Feb 1999 22:13:20 -0000
Received: from unknown (HELO sundance.stacken.kth.se) (130.237.234.41)
by bloom-picayune.mit.edu with SMTP; 5 Feb 1999 22:13:20 -0000
Received: (from majordom@localhost)
by sundance.stacken.kth.se (8.8.8/8.8.8) id XAA16605
for arla-drinkers-list; Fri, 5 Feb 1999 23:07:42 +0100 (MET)
Received: from mumrik.nada.kth.se (mumrik.nada.kth.se [130.237.226.10])
by sundance.stacken.kth.se (8.8.8/8.8.8) with ESMTP id XAA16600;
Fri, 5 Feb 1999 23:07:35 +0100 (MET)
Received: (from d95-mah@localhost)
by mumrik.nada.kth.se (8.8.7/8.8.7) id XAA05235;
Fri, 5 Feb 1999 23:07:12 +0100 (MET)
To: "Neulinger, Nathan R." <nneul@umr.edu>
Cc: Magnus Ahltorp <map@stacken.kth.se>, chuckl@netscape.com,
arla-drinkers@stacken.kth.se
Subject: Re: arla 0.21 Oops on Linux 2.2.1
References: <9DA8D24B915BD1118911006094516EAF019C7EDA@umr-mail02.cc.umr.edu>
From: Magnus Ahltorp <map@stacken.kth.se>
Date: 05 Feb 1999 23:07:12 +0100
In-Reply-To: "Neulinger, Nathan R."'s message of "Fri, 5 Feb 1999 15:54:38 -0600"
Message-ID: <ixd7ltwa4j3.fsf@mumrik.nada.kth.se>
Lines: 20
X-Mailer: Gnus v5.6.45/Emacs 19.34
Sender: owner-arla-drinkers@stacken.kth.se
Precedence: bulk
> The reason for my objection is that once you start wiring paths based on
> anything other than $(prefix), it becomes a pain to maintain for numbers of
> machines. In particular, locally we install everything to AFS, and
> occasionally overlay that onto the local machine.
>
> I personally really dislike it when I tell a product to install to
> /some/path and it goes and put's something in another directory. (Netatalk
> went and installed stuff into my pam directory for example.) If I hadn't of
> been paying complete attention, I never would have been able to take that
> install to another machine and have it work, since I wouldn't have been
> aware of that pam config file.
I agree. This is one of the reasons I didn't make libgetcwd.so install
into /lib. I will (as I have already said) consider making a separate
target for installation into /lib/modules. Personally, I don't really
see why it would be better to have xfs.o there, but as a separate
target, it will hopefully hurt noone.
/Magnus
map@stacken.kth.se
