Time has come to stop with /usr/local path pollution!

[Andrew Diederich]

I'd just ask that if a known bug isn't going to be fixed, it needs to be
documented and put upfront, big and large, where folks will see it.
Shutting off compiler warnings with gcc 3.2 is an example.  It broke
compile, but folks were talking about it on the list.  

Many of the developers, and people on this list, know about the problem, but
people who just download the software, read the docs, and try to install it
will get burned otherwise.  Then they'll curse the crappy software, and
they'll be right.  

There are three things to do when a bug is found.  1) fix it, 2) document
the bug and the workaround, or 3) hope people don't find it again.  #3 is
terribly expensive in support costs, like this string of emails.

--
Andrew Diederich

-----Original Message-----
From: Rob Siemborski [mailto:rjs3 at andrew.cmu.edu]

On Fri, 27 Sep 2002, Michael Newlyn Blake wrote:

> However it does seem that when explicit paths are called for certain
> componants they should be placed in line before the assumed system paths.
> That is to say, if you want to build and link against a libfoo in
> /snert/myjunk/foo-8.3.4 then this should be placed in the relevant paths
> before the include and lib dirs in /usr or /usr/local that are added
> automatically.

I agree 100% that the paths should be honored.  However, since it works
for most people, and testing is pretty annoying (as ken stated), I'm not
terribly eager to spend my time doing it, when I could be working on
performance or feature improvements elsewhere in the code.

If there was a patch provided that I could look at, approve, and apply,
I'd be willing to do so.  This is much less the case if I'm going to have
to read a bug report hidden inside of a rant that seems to assume that the
developers of Cyrus are part of a consipracy against all system
administrators everywhere.

-Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456
Research Systems Programmer * /usr/contributed Gatekeeper