Re: Time has come to stop with /usr/local path pollution!
However it does seem that when explicit paths are called for certain componants they should be placed in line before the assumed system paths. 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. Ah -- that is all I was waiting to hear. Patch will be coming up. 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. Wow. Somehow you got something (er, a lot of things!) from my message I never intended. All I was complaining about was that the application of the --with-path= stuff was very non-intuitive, and your average ./configure ; make ; make install person has no chance of figuring this out. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: Time has come to stop with /usr/local path pollution!
The next time somebody is frustrated by the software and wants to rant about how much of their time the developers wasted, take a step back and remember how much time and money they actually _saved_ you. Having been the guilty party which kicked off this thread, I want to step back and make myself clear. 1. Thank You! 2. I help as I can, although it often ends up being documentation or testing rather than code. 3. Sometimes that help is intended to save other users from running circles around a problem I ran circles around. Ultimately, this should reduce the amount of hand-holding you have to do, which makes your life easier. I was doing #2, found an issue and tried to do #3. This was the ultimate goal of my message, not to criticize anyone personally. I pretty much screwed up the tone of my message completely, and I really hope each of you will accept my deepest apologies. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: Time has come to stop with /usr/local path pollution!
First off, why did you feel the need to send this directly to me? Cyrus is not _my_ software, I'm just a contributor. Secondly, I can understand your frustration, but your shitty attitude ain't gonna help. Sorry, I misunderstood clearly, as I thought you were heading up the imapd 2.2 branch. A lot of bitching, and no proposed fixes. It works for me, and I'm sure it works for CMU, otherwise it would've been fixed already. Since I I would happily submit a patch .. but I want to make sure it would be accepted or at least considered. I've lost too much time over the years putting together a clean patch to fix something only to find that the maintainers had no interest in _ever_ accepting said patch. So I toss out a query about it before I do it. And before you say Then why the complaint? -- because I did toss out such a query. Twice. Once on this list, and once on the SASL list. With no takers on the issue. Have people forgotten how much they _paid_ for this software? What is the ROI and/or price performance of this software for ISPs, freakin' infinity? Why is it assumed that each user is _entitled_ to some level of technical support? Not asking for technical support. Suggesting that this may solve a lot of the compilation support issues you guys receive on the list. -- Joe Rhett Chief Geek [EMAIL PROTECTED] ISite Services, Inc.
Re: Time has come to stop with /usr/local path pollution!
On Sat, 28 Sep 2002, Carson Gaspar wrote: --On Friday, September 27, 2002 10:34 AM -0400 Ken Murchison [EMAIL PROTECTED] wrote: A lot of bitching, and no proposed fixes. It works for me, and I'm sure I have submitted patches in the past to fix this dain-bramaged configure behaviour. They have been ignored. Lots of the --with-foo options are implemented badly in configure.in. I'd like to fix them, but can't until the maintainers stop insisting on supporting autoconf-2.13. Well, the problem is: autoconf is a through and through bitch to support :-) CMU has a shared tree of m4 macros, I think we'd need to send them the full port of all the stuff in cmulocal/, plus of all the stuff that _uses_ it (unless cmulocal is made to be autoconf-version agnostic). I know SASL and Cyrus both share the same AFS cmulocal/ dir even... At this point, I've basically given up, and just manually hack configure to be non-idiotic before I configure a new release. Well, I can actually testbed the configure changes for you, and use them for the Debian builds... But my requirements re. cmulocal are very different (aka. as long as it works for Debian's Cyrus build) than CMU's. However, since my build env. is _very_ well behaved and all the stuff is under /usr, it gets somewhat difficult to spot bugs in the find-the-foo paths from configure.in :-) -- One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie. -- The Silicon Valley Tarot Henrique Holschuh
Re: Time has come to stop with /usr/local path pollution!
Quoting Rob Siemborski [EMAIL PROTECTED]: On Sun, 29 Sep 2002, Henrique de Moraes Holschuh wrote: Well, I can actually testbed the configure changes for you, and use them for the Debian builds... But my requirements re. cmulocal are very different (aka. as long as it works for Debian's Cyrus build) than CMU's. However, since my build env. is _very_ well behaved and all the stuff is under /usr, it gets somewhat difficult to spot bugs in the find-the-foo paths from configure.in :-) This is actually a lot of our problem as well. All of our machines are very specifically facilitized to be nearly identical. Thus, it may work for us, but we really only have one setup to look at. I also do some testing on some pretty stock RedHat machines, but that's all I generally have time for configure-wise. Bug #1386 is a tracking of our progress towards getting autoconf 2.50+ happy with Cyrus SASL. At this point (as far as I know), autoconf 2.50+ should be working with Cyrus SASL modulo some quoting issues in the --help output of configure, so this should imply that cmulocal should be happy with 2.50+ as well. (A lot of this work is credited to Carlos Velasco, who went to great lengths to work with us so that none of his changes broke a 2.13 build either). There isn't currently a bug tracking the progress for Cyrus IMAPd, since, well, no one has volunteered to do the work yet to both make it work with 2.53 *and* keep it working with 2.13. (And, well, that's definately a battle we're not willing to fight on our own yet, since it *is* working for us). 2.13/2.53 _should_ both work with Cyrus (CVS). In fact, I tested and committed Carlos' patches before he started working on the SASL stuff. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
RE: Time has come to stop with /usr/local path pollution!
Quoting Andrew Diederich [EMAIL PROTECTED]: 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. Its seems that people are missing a very important point here. Cyrus was developed for internal use at CMU. CMU has been kind enough to allow the source code to be distributed for use by anybody, commercial or otherwise. Some may argue that CMU has a responsibility to fix all bugs, write good documentation, hand-hold ignorant/illiterate admins, make coffee, and clean windows. In most cases, they do all of the above, and more. I wish people would keep this in mind, when they claim that the build process is broken. It is broken for _you_, because I can assure you that it built for the intended user (CMU). The developers first responsibilty is to their employers, not to a small, whiny part of the user community with an edge-case problem. If people spend the same amount of time trying to fix the problem instead of bitching about it, this would've been a dead issue a long time ago. It don't think that the squeaky wheel gets the grease principal is necessarily going to work. The next time somebody is frustrated by the software and wants to rant about how much of their time the developers wasted, take a step back and remember how much time and money they actually _saved_ you. Another $.02 -Original Message- From: Rob Siemborski [mailto:[EMAIL PROTECTED]] 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 -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
RE: Time has come to stop with /usr/local path pollution!
I'm going to throw out my opinion too.. Please no flames. This isn't directed at anyone -- just my observations after using/maintaining Cyrus for 4 years (v1.5.19 still in production) First, CMU places a nice disclaimer in the docs. Cyrus is on the same order of NetNews to install -- historically compiling/installing/maintaining news server software has been a daunting task at best. When we started w/ Cyrus (1998) it was a big departure from the traditional mbox mail system. Even today if you want a simple to install mailsystem use mbox+/var/mail. Cyrus is a much more robust system and as a result requires more time and experience to install. Additionally, if you are trying to build a big mail system you better have more experience than I've installed Linux a few times. Building large, scalable, and secure mail systems requires experience, patience and usually lots of caffeine and little sleep. (subscribing to this list helps too) Second, opensource does NOT work unless people contribute. CMU developed and maintains this software for their own use -- the rest of us get a free ride. I really appreciate the contributions Ken and others have made to the project. If you find something you don't like/think needs changing do what the rest of us do - change it and contrib it back to CMU. The current group of Cyrus developers have been great w/ working with outside patches etc. (users since v1 will remember those days when CMU was just trying to make it work ;-) ) Cyrus has been instrumental in our organizations conversion to opensource. Without Cyrus, we'd be running Groupwise or M$ Exchange ick! If Cyrus is too complicated / difficult for you to install/maintain go hire someone who can or purchase one of the above mentioned packages. Some important points: 1) Many thanks to CMU for releasing and trying to support this great software. 2) You get what you pay for (in this case remember the code is free) 3) If it breaks -- you get to keep both pieces -- but ask nicely many of us have broken Cyrus too. 4) Participate -- subscribe to the list, submit docs fixes etc if you can, discuss issues on the list, don't post bitching about this or that unless you are willing to do something about it. 5) If you don't like #4 quit wasting our time.. Paul Satisfied Cyrus user contributor since v1.5.14 On Sat, 28 Sep 2002, Ken Murchison wrote: Quoting Andrew Diederich [EMAIL PROTECTED]: 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. Its seems that people are missing a very important point here. Cyrus was developed for internal use at CMU. CMU has been kind enough to allow the source code to be distributed for use by anybody, commercial or otherwise. Some may argue that CMU has a responsibility to fix all bugs, write good documentation, hand-hold ignorant/illiterate admins, make coffee, and clean windows. In most cases, they do all of the above, and more. I wish people would keep this in mind, when they claim that the build process is broken. It is broken for _you_, because I can assure you that it built for the intended user (CMU). The developers first responsibilty is to their employers, not to a small, whiny part of the user community with an edge-case problem. If people spend the same amount of time trying to fix the problem instead of bitching about it, this would've been a dead issue a long time ago. It don't think that the squeaky wheel gets the grease principal is necessarily going to work. The next time somebody is frustrated by the software and wants to rant about how much of their time the developers wasted, take a step back and remember how much time and money they actually _saved_ you. Another $.02 -Original Message- From: Rob Siemborski [mailto:[EMAIL PROTECTED]] 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
RE: Time has come to stop with /usr/local path pollution!
I am new to cyrus and the info-cyrus mailing list, but am a long time unix administrator and developer. Sendmail offers a similar product to cyrus, but lacking in some of the new features, for a large price tag. I prefer to deal with a few compilation gliches, provided the software works reliably once installed. If I can contribute in any way, I will. Thank you for making this software publicly available. I suspect it is far more popular than the developers originally anticipated. -- Tom Andrews Team Leader / Server Manager Campus Computing University of Nevada, Reno Quoting Paul Fleming [EMAIL PROTECTED]: I'm going to throw out my opinion too.. Please no flames. This isn't directed at anyone -- just my observations after using/maintaining Cyrus for 4 years (v1.5.19 still in production) First, CMU places a nice disclaimer in the docs. Cyrus is on the same order of NetNews to install -- historically compiling/installing/maintaining news server software has been a daunting task at best. When we started w/ Cyrus (1998) it was a big departure from the traditional mbox mail system. Even today if you want a simple to install mailsystem use mbox+/var/mail. Cyrus is a much more robust system and as a result requires more time and experience to install. Additionally, if you are trying to build a big mail system you better have more experience than I've installed Linux a few times. Building large, scalable, and secure mail systems requires experience, patience and usually lots of caffeine and little sleep. (subscribing to this list helps too) Second, opensource does NOT work unless people contribute. CMU developed and maintains this software for their own use -- the rest of us get a free ride. I really appreciate the contributions Ken and others have made to the project. If you find something you don't like/think needs changing do what the rest of us do - change it and contrib it back to CMU. The current group of Cyrus developers have been great w/ working with outside patches etc. (users since v1 will remember those days when CMU was just trying to make it work ;-) ) Cyrus has been instrumental in our organizations conversion to opensource. Without Cyrus, we'd be running Groupwise or M$ Exchange ick! If Cyrus is too complicated / difficult for you to install/maintain go hire someone who can or purchase one of the above mentioned packages. Some important points: 1) Many thanks to CMU for releasing and trying to support this great software. 2) You get what you pay for (in this case remember the code is free) 3) If it breaks -- you get to keep both pieces -- but ask nicely many of us have broken Cyrus too. 4) Participate -- subscribe to the list, submit docs fixes etc if you can, discuss issues on the list, don't post bitching about this or that unless you are willing to do something about it. 5) If you don't like #4 quit wasting our time.. Paul Satisfied Cyrus user contributor since v1.5.14 On Sat, 28 Sep 2002, Ken Murchison wrote: Quoting Andrew Diederich [EMAIL PROTECTED]: 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. Its seems that people are missing a very important point here. Cyrus was developed for internal use at CMU. CMU has been kind enough to allow the source code to be distributed for use by anybody, commercial or otherwise. Some may argue that CMU has a responsibility to fix all bugs, write good documentation, hand-hold ignorant/illiterate admins, make coffee, and clean windows. In most cases, they do all of the above, and more. I wish people would keep this in mind, when they claim that the build process is broken. It is broken for _you_, because I can assure you that it built for the intended user (CMU). The developers first responsibilty is to their employers, not to a small, whiny part of the user community with an edge-case problem. If people spend the same amount of time trying to fix the problem instead of bitching about it, this would've been a dead issue a long time ago. It don't think that the squeaky wheel gets the grease principal is necessarily going to work. The next time somebody is
RE: Time has come to stop with /usr/local path pollution!
Thanks for the help, Rob. -- Andrew From: Rob Siemborski [mailto:[EMAIL PROTECTED]] On Fri, 27 Sep 2002, Andrew Diederich wrote: 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. I have committed these two bugs to bugzilla as #1423 and #1424. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: Time has come to stop with /usr/local path pollution!
On Sat, Sep 28, 2002 at 08:44:52AM -0400, Ken Murchison wrote: Quoting Andrew Diederich [EMAIL PROTECTED]: 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. Its seems that people are missing a very important point here. Cyrus was developed for internal use at CMU. CMU has been kind enough to allow the source code to be distributed for use by anybody, commercial or otherwise. CMU scratched its itch, and released to code. No complaint here. Some may argue that CMU has a responsibility to fix all bugs, write good documentation, hand-hold ignorant/illiterate admins, make coffee, and clean windows. In most cases, they do all of the above, and more. Since there is no contract between CMU, Cyrus developers, and folks who download Cyrus, it's absolutely not CMU's responsibility to do anything. I wish people would keep this in mind, when they claim that the build process is broken. It is broken for _you_, because I can assure you that it built for the intended user (CMU). The developers first responsibilty is to their employers, not to a small, whiny part of the user community with an edge-case problem. Sure, Cyrus is there to scratch your itch. It happens to work for some others, too. I'd have to argue that installing the Berkeley DB in its default location is a little far from an edge-case problem, though. If people spend the same amount of time trying to fix the problem instead of bitching about it, this would've been a dead issue a long time ago. It don't think that the squeaky wheel gets the grease principal is necessarily going to work. Yup. And some of that is taking what feedback you get from users, and deciding what to do with it. There really are only the three things you can do with a bug. Remember that its really hard to get user feedback. Even if a bug report doesn't include a patch, its usually better than not getting it at all. For every one guy that says it surprised me when this happened there are nine that were surprised and didn't say anything. And there are even fewer that tell you _why_ they were surprised, and what really happened. The next time somebody is frustrated by the software and wants to rant about how much of their time the developers wasted, take a step back and remember how much time and money they actually _saved_ you. Another $.02 Open source software does tend to save money. And a good, helpful user community like this one, and sunmanagers, all adds to the value of a product. Thanks for the time to read this. -- Andrew Diederich
Re: Time has come to stop with /usr/local path pollution!
--On Friday, September 27, 2002 10:34 AM -0400 Ken Murchison [EMAIL PROTECTED] wrote: A lot of bitching, and no proposed fixes. It works for me, and I'm sure I have submitted patches in the past to fix this dain-bramaged configure behaviour. They have been ignored. Lots of the --with-foo options are implemented badly in configure.in. I'd like to fix them, but can't until the maintainers stop insisting on supporting autoconf-2.13. At this point, I've basically given up, and just manually hack configure to be non-idiotic before I configure a new release. -- Carson
Re: Time has come to stop with /usr/local path pollution!
soap box First off, why did you feel the need to send this directly to me? Cyrus is not _my_ software, I'm just a contributor. Secondly, I can understand your frustration, but your shitty attitude ain't gonna help. Joe Rhett wrote: We really must stop with the path pollution that you guys include into the configuration process. I just lost 2 hours trying to figure out why it couldn't find a db3_nosync function... and finally figured out that you were looking at a path I never specified ( /usr/local/include ) and reading the include files from there, instead of the path I did specify: --with-dbdir=/opt/berkeleydb If I want you to read /usr/local, I'll tell you that. Please stop assuming that everything is dumped there. At the very least, try the specified path and only try /usr/local if nothing was specified. You've had more than a dozen complaints about stuff picking up the wrong libraries, when the properly library paths were explicitly listed. A lot of bitching, and no proposed fixes. It works for me, and I'm sure it works for CMU, otherwise it would've been fixed already. Since I don't have a problem, I'm not going to go through the trouble of trying to reproduce it just so I can fix it. Unless you hear differently from somebody at CMU, I'm going to assume that one of the dozen or so people with this problem are going to have to fix it and hopefully submit a patch. Have people forgotten how much they _paid_ for this software? What is the ROI and/or price performance of this software for ISPs, freakin' infinity? Why is it assumed that each user is _entitled_ to some level of technical support? Stuff like this makes me really happy that I added virtdomains support for FREE!!!, so that the ISPs can make even more money with less admin overhead. /soap box On Thu, Sep 26, 2002 at 03:30:54PM -0700, Joe Rhett wrote: This problem continues to exist in CVS. The problem is that you aren't including the include path specified by --with-sasl when you compile and run the test program. SASL is installed in /opt/sasl. I'm using the configuration options listed below. I get the output listed below. If I go into /usr/lib/include and type ln -s /opt/sasl/include/sasl then the configure runs perfectly fine. The relevant line is at 5348 in the configure generated on my system. ac_try=$ac_cpp conftest.$ac_ext /dev/null 2conftest.out There's no use of $CPPFLAGS to pick up the --with-sasl includes or libs. Again, you don't notice this because you pollute the includes and libs with /usr/local automatically, even when it isn't relevant and can be harmful. Please fix the autoconf to use the --with-sasl options when building conftest. On Tue, Aug 20, 2002 at 09:12:16PM -0700, Joe Rhett wrote: Configure problem with cyrus-imapd CVS version -- it's not seeing --with-sasl at all. ./configure --prefix=/opt/imapd --with-cyrus-prefix=/opt/imapd --with-sasl=/opt/sasl --with-openssl=/opt/openssl --with-dbdir=/opt/berkeleydb ...etc... checking for sasl/sasl.h... yes checking for sasl/saslutil.h... yes checking for prop_get in -lsasl2... yes configure: error: Incorrect SASL headers found. This package requires SASL 2.1.7 or newer. However, the only sasl.h on the system is in /opt/sasl/include/sasl/ ... Commenting out the rm conftest* in 'configure' and then checking the output of the test program shows... cyclops 151% cat conftest.out configure:5278: sasl/sasl.h: No such file or directory configure:5281: #error SASL_VERSION_MAJOR not defined configure:5284: #error SASL_VERSION_MINOR not defined configure:5287: #error SASL_VERSION_STEP not defined configure:5291: #error SASL version is less than 2.1.7 I can't quite figure out why this isn't working, but the sasl.h and libsasl2 tests are -- maybe you have a clue? On Wed, Aug 14, 2002 at 10:38:35AM -0700, Joe Rhett wrote: Nope. We had to downgrade so that I could work with your CVS stuff. Most annoying. On Mon, Aug 12, 2002 at 06:52:40PM -0400, Ken Murchison wrote: Did you upgrade to a new version of autoconf? Only v2.13 will work (currently). Joe Rhett wrote: On Fri, Aug 09, 2002 at 09:46:42PM -0400, Ken Murchison wrote: Joe Rhett wrote: Well, that's part 2 --- sasl won't compile for me any more. Whoa! Did you try: make distclean rm configure aclocal.m4 sh SMakefile aclocal.m4 doesn't exist for me, and configure never got far enough to make a real Makefile so make distclean doesn't work -- but yeah, that's exactly what I've done. cyclops% sh SMakefile aclocal -I cmulocal -I config aclocal: configure.in: 80: macro `AM_DISABLE_STATIC' not found in library aclocal: configure.in: 82: macro `AM_PROG_LIBTOOL' not found in library
Re: Time has come to stop with /usr/local path pollution!
On Fri, 27 Sep 2002, Ken Murchison wrote: were looking at a path I never specified ( /usr/local/include ) and reading the include files from there, instead of the path I did specify: --with-dbdir=/opt/berkeleydb Now... I'm just guessing at the problem here. Is he saying that he has a different version of berkleydb in /usr/local than the one he's trying to build against, which is in /opt/bekreleydb, and that having /usr/local/include in the search path first is breaking the configure process? A lot of bitching, and no proposed fixes. It works for me, and I'm sure it works for CMU, otherwise it would've been fixed already. Since I True, but he does seem to be bringing up an important stylistic issue in how configure processes options, perhaps even in how it arranges the build environment. I won't go into the issue of whether or not /usr/local/include should be used, as he never specifies whether he'd changed his prefix to something else and it seems quite reasonable to treat the include and lib areas of the prefix as general system areas. 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. Cheers. - /\Michael Newlyn Blake [EMAIL PROTECTED] \ oo / \\|\mm \ / GAT d- s-:++ a? C+++ UL P+ L+++ E--- W++ //_//\ \_\ \ /N+ o-- K--- w--- O- M V-- PS+ PE Y+ PGP t++ /K-9/ \/_/ X 5+ X+ R tv+ b+++ DI++ D+ G-- e h--- r+++ y+++ /___/_\ / \ --- ASCII Ribbon Campaign Against HTML Mail
Re: Time has come to stop with /usr/local path pollution!
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
RE: Time has come to stop with /usr/local path pollution!
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:[EMAIL PROTECTED]] 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
RE: Time has come to stop with /usr/local path pollution!
On Fri, 27 Sep 2002, Andrew Diederich wrote: 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. I have committed these two bugs to bugzilla as #1423 and #1424. -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
