Leigh Jones writes: I don't want to tread on toes too very hard here.
It seems to me that Sam Varshavchik has been clear here, but the brevity with which he has spoken belies the depth of meaning. So let me attempt to expound. If you come from the background of running a very "tiny" linux implementation, as in not particularly well supported, you may miss entirely the strength of a very "large" linux implementation. FSF software can be compiled and run with some degree of success on a Debian system. But to make full use of the Debian linux implementation you need to "hook in" to the full strength of the Debian organization. Debian has locations for system files that it considers to be "just so". As soon as you start compiling FSF programs over the top of Debian linux you will start to misplace files. For instance, openssl wants all of the certificate files that it uses to be located in a particular place, and the default location for these certificate files is decided at compile time. Type "openssl version -d". If you compile the openssl program yourself, you can manage that location with command line options, and put it where you want it. But if you haven't carefully studied the Debian party line you probably won't know where that is. So if you use apt-get to grab openssl from the Debian servers you will get back "/usr/lib/ssl" in response to "openssl version -d", but if you try the same thing with an RPM package for Red Hat on a Red Hat system you'll get a different directory. Now, Sam Varshavchik could probably quote you verse and line on where Debian puts all the files in a Courier e-mail server and would probably tell you why he wishes they would accept the default locations. But Debian puts Courier here and Apache there and Apache-SSL somewhere else, and all the files would probably be found in a different location on Red Hat. Then Debian builds packages for apt so that they locate everything just so. So if you keep on installing the required software using apt-get or Synaptic Package Manager or Debian's Update Manager, then you will keep getting software packages that don't have any conflicts on installation, and you will have fewer copies of libraries all over everywhere. That gets to be important, because the library updates need to be managed to prevent that updating one software package doesn't break another. Debian does this extremely well, and has more FSF software available on their servers than any other linux implementation. And a number of popular linux implementations such as Ubuntu are essentially Debian at heart, so packages from the Debian servers may work pretty well on Ubuntu. Red Hat, and of the "nearly Red Hat" implementations such as Centos also do it very well, but the choice of RPM packages that are ready to go might not allow you to run Courier. Well, frankly, Debian doesn't really allow you to run the most current version of Courier using apt-get, etc. They won't update my Debian Etch Courier 0.53.3 right now, anyway, and I sure would like the Courier 0.57 stuff instead. Oh well. Nothing's perfect, but frankly working within the system seems pretty smart with Debian. I can tell you that Apache with Openssl and Courier with Openssl work straight out of the box without doing any compiling using Debian and apt-get. And before too long Debian will get around to providing more current versions of Courier. Lydiard writes: > ----- Message from [EMAIL PROTECTED] -------- >> Lydiard writes: >> >>> I am running debian >>> I downloaded the source of courier-imap-4.2.1 >>> I unpacked it as a user >>> All commands that I've run to date have been as non-root >>> >>> I am using these flags >>> CPPFLAGS="-I/usr/include/openssl -I/usr/local/include/openssl" >> >> Why? > > God, I've missed you :) > >> Why are you not using Debian's OpenSSL package? > > Cos Apache wouldn't compile with it And why do you want to compile Apache? Debian also has a perfectly fine Apache package. >> The standard OpenSSL library does not get installed in /usr/local. This >> must be some custom version of OpenSSL that you installed, and it's not >> built correctly. OpenSSL must be built as a shared library, not as a >> static library. > > I'm starting to think it may be the version/installation of make No, it's not. > that's the issue - postfix is choking as well (but not on the TLS). Maybe, but if the compile gets to the linking stage, it'll choke on it in exactly the same way. >> You need to clean up your system and remove all duplicate libraries and >> binaries that you installed yourself, that conflict with existing >> Debian packages, and are giving you these problems for no good reason. >> Debian has perfectly working OpenSSL runtime and development libraries, >> and there is no good reason to waste your time installing some mutated >> version of OpenSSL into /usr/local. >> >> Just use the standard Debian software libraries to build your code. > > Sam - tbh, if that's your opinion, I'm inclined to go with it. And > whilst it's not your problem, what will happen to Apache if I rip out > the OpenSSL? Debian should not let you rip out openssl if you have Apache installed, because Apache requires OpenSSL. ------------------------------------------------------------------------- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 _______________________________________________ courier-users mailing list [email protected] Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users
