Subject: [PATCH] port of WU-IMAPD to SuSE Linux

From: Friedrich Lobenstock <[email-masked]>
Date: Wed, 23 Jan 2002 18:51:24 +0100 (CET)

Hi!

I found that there is already a port for Redhat Linux so I didn't
hassitate to make one for SuSE Linux and here it is. Hope this get's
applied to the next release of wu.imapd.

-- 
MfG / Regards
Friedrich Lobenstock

diff -Nur imap-2002.DEV.SNAP-0201222215/Makefile imap-2002.DEV.SNAP-0201222215-suse/Makefile
--- imap-2002.DEV.SNAP-0201222215/Makefile	Tue Oct 23 06:46:33 2001
+++ imap-2002.DEV.SNAP-0201222215-suse/Makefile	Wed Jan 23 18:22:25 2002
@@ -282,6 +282,11 @@
 	$(BUILD) BUILDTYPE=lnp \
 	SPECIALS="GSSDIR=/usr/kerberos SSLDIR=/usr/share/ssl SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib"

+# SuSE Linux
+lxs:	an
+	$(BUILD) BUILDTYPE=$@ \
+	SPECIALS="SSLTYPE=unix SSLDIR=/usr/ssl SSLINCLUDE=/usr/include/openssl SSLLIB=/usr/lib"
+

 # Linux shadow password support doesn't build on traditional systems, but most
 # Linux systems are shadow these days.
diff -Nur imap-2002.DEV.SNAP-0201222215/src/osdep/unix/Makefile imap-2002.DEV.SNAP-0201222215-suse/src/osdep/unix/Makefile
--- imap-2002.DEV.SNAP-0201222215/src/osdep/unix/Makefile	Fri Nov 30 20:10:06 2001
+++ imap-2002.DEV.SNAP-0201222215-suse/src/osdep/unix/Makefile	Wed Jan 23 17:43:00 2002
@@ -435,6 +435,15 @@
 	 BASECFLAGS="-g -fno-omit-frame-pointer -O6" \
 	 BASELDFLAGS="-lpam -ldl"

+lxs:	# SuSE Linux
+	$(BUILD) `$(CAT) SPECIALS` OS=lnx \
+	 SIGTYPE=psx CHECKPW=pam CRXTYPE=nfs \
+	 SPOOLDIR=/var/spool \
+	 ACTIVEFILE=/var/lib/news/active \
+	 RSHPATH=/usr/bin/rsh \
+	 BASECFLAGS="-O2" \
+	 BASELDFLAGS="-lpam -ldl"
+
 lnx:	# Linux non-shadow passwords
 	@echo You are building for traditional Linux *without* shadow
 	@echo passwords and with the crypt function in the C library.

-- 
------------------------------------------------------------------
 For information about this mailing list, and its archives, see: 
 http://www.washington.edu/imap/c-client-list.html
------------------------------------------------------------------

---

From: Mark Crispin <[email-masked]>
Date: Wed, 23 Jan 2002 10:01:22 -0800 (PST)

I've added lsu for SuSE Linux to the sources based upon your patches.  There
are some other differences:

1) Official sources never set SSLTYPE by default.  You have to specify that
   you want an SSL build.

2) lsu uses the lnp buildtype.  The only difference in your patch was to the
   CFLAGS.  Official sources always set -g

---

From: Friedrich Lobenstock <[email-masked]>
Date: Wed, 23 Jan 2002 19:14:44 +0100 (CET)

>    CFLAGS.  Official sources always set -g

add 1) and 2)
 SSLTYPE and CFLAGS are specific to SuSE and it's a special port of Linux

-- 
MfG / Regards
Friedrich Lobenstock

---

From: Sebastian Hagedorn <[email-masked]>
Date: Wed, 23 Jan 2002 19:27:51 +0100

--On Wednesday, January 23, 2002 19:14:44 +0100 Friedrich Lobenstock 
<[email-masked]> wrote:

>> I've added lsu for SuSE Linux to the sources based upon your patches.
>> There are some other differences:
>>
>> 1) Official sources never set SSLTYPE by default.  You have to specify
>> that you want an SSL build.
>>
>> 2) lsu uses the lnp buildtype.  The only difference in your patch was to
>> the CFLAGS.  Official sources always set -g
>>
>
> add 1) and 2)

Whatever is that supposed to mean? Why should the SuSE port be different 
from every other port in that respect?

There is a reason why the flags are what they are...

Greetings, Sebastian
--
Sebastian Hagedorn
Ehrenfeldgürtel 156
50823 Köln
http://www.spinfo.uni-koeln.de/~hgd/

Winter is coming.

---

From: Mark Crispin <[email-masked]>
Date: Wed, 23 Jan 2002 10:41:06 -0800 (PST)

> from every other port in that respect?

Thank you.  I was about to answer the same thing.

All UW IMAP documentation is based upon a standard distribution, and that
standard has proved to be a good thing.  I understand why third party OS
vendors wish to modify the software (e.g. to comply with *their* standard!);
however, the burden of such modifications belongs with them.

Of course, the UW distribution must have some platform-specific modifications.
Those modifications are limited to what is necessary to make the software
build and operate according to the UW standard on that platform.

Options such as SSL are options are on all platforms.  Turning on SSL adds
external dependencies.  I know for a fact that RedHat does not guarantee that
those dependencies will be met.  I doubt that SuSE does either.  I don't know
of a single UNIX-based operating system which does.

> There is a reason why the flags are what they are...

Yup.  To clarify my position on -g:

I am frequently asked to turn off -g for a build on a particular port, and
from time to time a submitted port has snuck in without -g.  This has *always*
ended up causing problems.  There are only two valid excuses for not using -g
in a port:
 1) The compiler does not support -g
 2) An alternate form of -g is needed with optimization, e.g. -g3.
There will be no new ports added without -g (or alternative) being set.

Processors are fast enough (and disk space is cheap enough) that -g should be
automatic in all compilers with no way of turning it off, and /bin/strip
should be a symlink to /bin/true.  Human life is too short to deal with
binaries built without -g.  Such binaries should be an evil memory of the days
of KIPS processors and disks that costs several dollars per kilobyte.

I have not arbitrarily added -g to the ports which do not currently have it
because I don't know if doing so would break the build.  However, any support
issues with one of those port *will* lead to the correct -g setting being
determined and permanently added.

---

From: Raul Dias <[email-masked]>
Date: Wed, 23 Jan 2002 17:48:42 -0200

Mark Crispin <[email-masked]> wrote:
[	****	]
>of a single UNIX-based operating system which does.

I do it easily with rpm. BuildRequires, Requires and automatic requires take care
of this nicely (I believe .debs do it too).

>There will be no new ports added without -g (or alternative) being set.

I agree with you in the sense of supporting and debugging without it would be
impossible.

>binaries built without -g.  

I disagree with you in this point.
If a software is know to work right, there is no point in keeping unecessary
symbols in its binaries that usually slows down its performance.
This is an important point on high load servers, for example.

If there is a problem, the user should recompile it with the debugs turned
on.

Of course, I do agree that it is the user/packager 's job to strip this
and not the pristine source.

> Such binaries should be an evil memory of the days

It still is.  Regarding some cache memories in the CPUs.
In some cases keeping the binary small, might make it stay in the 
cache memory longer without the need to be swapped to the main memory,
giving a burst during its execution.

Best Regards,

Raul Dias

---

From: Mark Crispin <[email-masked]>
Date: Wed, 23 Jan 2002 13:51:43 -0800 (PST)

On Wed, 23 Jan 2002 17:48:42 -0200, Raul Dias wrote:
> >external dependencies.  I know for a fact that RedHat does not guarantee
> >that those dependencies will be met.  I doubt that SuSE does either.  I
> >don't know of a single UNIX-based operating system which does.
> I do it easily with rpm. BuildRequires, Requires and automatic requires take
> care of this nicely (I believe .debs do it too).

Really?  You can refuse to install an imapd built with SSL if proper
certificates are not installed first?

> This is an important point on high load servers, for example.

Do you have any measure on exactly how much -g "slows down its performance"?
I can understand that some stack optimizations can't be done, but how much
does that really affect the performance of imapd?

> giving a burst during its execution.

What modern operating system loads the segment -g symbols into a running
process' address space?

TOPS-20 did, but since that was a demand-paged system the memory pages with
the symbols generally never got paged in from the binary unless you invoked
the debugger.

Since UNIX debuggers don't work the way that the TOPS-20 debugger did, I see
no reason for a UNIX process ever to have symbols loaded.

---

From: Friedrich Lobenstock <[email-masked]>
Date: Wed, 23 Jan 2002 23:04:57 +0100 (CET)

> however, the burden of such modifications belongs with them.

First I have to state that I'm in now way connected to this vendor. I
just wanted to give users of this distribution the correct paramters
which I would like to document in let's say README.SuSE. So everybody
who uses the SuSE ports get's the default SuSE paramters rigth away
and knows what other software he needs to have in place so the build
will work. Your standard documentation can stay the same.

So I don't see why this is such a problem for you. Otherwise the whole
port thing is useless, just document all available parameters and your
done.

> Yup.  To clarify my position on -g:

If someone wants to debug a software he recompiles it with -g to get
debugging symbols, so I don't see your point either.

-- 
MfG / Regards
Friedrich Lobenstock

---

From: Raul Dias <[email-masked]>
Date: Wed, 23 Jan 2002 18:09:58 -0200

>certificates are not installed first?

I agree. I was more focused on library dependencies than this.
This can be solved too by using pre/post install scripts as some 
distributions do for bind and apache.

But it is the admin's job to know what he is installing and checing that.

>does that really affect the performance of imapd?
I don't know.

>no reason for a UNIX process ever to have symbols loaded.

I didn't know this.  If it is not loaded, there isn't no point on not using 
-g.

Regards,

Raul Dias

---

From: Mark Crispin <[email-masked]>
Date: Wed, 23 Jan 2002 14:11:03 -0800 (PST)

> But it is the admin's job to know what he is installing and checing that.

Unfortunately, that has proven not to be a trustworthy assumption.  Many
admins are, uh, "clue-impaired" when it comes to matters like this.

> >Since UNIX debuggers don't work the way that the TOPS-20 debugger did, I
> >see no reason for a UNIX process ever to have symbols loaded.

That's my belief.

---

From: Mark Crispin <[email-masked]>
Date: Wed, 23 Jan 2002 14:20:32 -0800 (PST)

On Wed, 23 Jan 2002, Friedrich Lobenstock wrote:
> which I would like to document in let's say README.SuSE.

The problem is that what is "correct" is not platform-specific.  If
something is mandatory in one platform and optional in another, then a
manager dealing with multiple platforms has to keep track of which one he
has to set SSLTYPE=unix and which one is automatic.

> port thing is useless, just document all available parameters and your

What's useful is defining the directories.

> debugging symbols, so I don't see your point either.

That "someone" is *me*.  I frequently get support requests which require
me to check out the problem on the user's own system.

-- Mark --

http://staff.washington.edu/mrc
Science does not emerge from voting, party politics, or public debate.

---

From: Friedrich Lobenstock <[email-masked]>
Date: Wed, 23 Jan 2002 23:27:05 +0100 (CET)

> has to set SSLTYPE=unix and which one is automatic.

This is the problem of not correct ports. Ports that don't use all
defaults for a plattform are worthless in my opinion.

> What's useful is defining the directories.

The more complete a port is the more useful it is.

> me to check out the problem on the user's own system.

Then please put this in a readme.

-- 
MfG / Regards
Friedrich Lobenstock