Leigh,

you' did a pretty good job in explaining it. For about 2 years or so Debian was only offering outdated packages and even I started to compile packages. While I greatly appreciate the 'standard file locations' and dependencies Debian enforces there may be good reasons to recompile a Debian package e.g. if command line values need to be changed. In such case I download the Debian source files (original source plus Debian diff), change the compile parameters in debian/rules and build the packges. This normally works UNLESS there are major program changes.

Therefor, in conclusion and for the benefit of any other reader, if you need to change some compile parameters you should NOT download the tarball and compile it but the original source together with the Debian diff file and then recompile it.

Just my 2 yen.

Thanks, Bernd

--- 差出人: "Leigh S. Jones, KR6X" <kr...@kr6x.com> 宛先:: cour...@lists.sourceforge.net 件名: Re: [courier-users] Error compiling Courier with TLS 日付: Thu, 29 Nov 2007 18:06:17 -0800

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 o

-- プラゲ ベェアント - Bernd Plagge ファースト・チョイス・インターネット(有) First Choice Internet Ltd., Tokyo Tel. 03-4500-7799 Fax. 03-4400-3723 mail: bpla...@choicenet.ne.jp url: http://www.choicenet.ne.jp

------------------------------------------------------------------------- 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 cour...@lists.sourceforge.net Unsubscribe: https://lists.sourceforge.net/lists/listinfo/courier-users

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:

And why do you want to compile Apache? Debian also has a perfectly fine Apache package.

No, it's not.

Maybe, but if the compile gets to the linking stage, it'll choke on it in exactly the same way.

Debian should not let you rip out openssl if you have Apache installed, because Apache requires OpenSSL.