Subject: Re: [netatalk-admins] a cold wind bloweth

From: [email-masked]
Date: Tue, 25 May 1999 15:38:57 -0400

> From:    a sun <[email-masked]>
> To:      [email-masked]

> when i get all of the kinks out of the code, i usually turn off most
> of the options. that usually makes it easier to compile. i do tend to
> leave the tcp wrapper stuff on though. having a little configure
> script that does feature tests and goes through and edits the Makefile
> for you would be ideal.

I recently built asun 2.1.3.  My largest complaint is how difficult it
was to build correctly.  I agree that tcp wrappers should be the
default for the AFP/TCP support.  I'm not in favor of configure
scripts.  I think most decisions can be made with only the system
version.  In the case of Linux, I think we should probably be creating
RPMs, since version skew is so rampant.

> anyways, i'd be more than happy to get
> prototypes and stuff for the code to incorporate. 

Well, let's try to focus on making this frozen version netatalk 2.0.
That, I think ought to include a source review/update for
ansi/posix/modern coding standards.

:wes

---

From: chuck <[email-masked]>
Date: Tue, 25 May 1999 13:05:00 -0700

I have to say the 'global makefile' thing rarely works - there
are too many platforms/makes out there.  As someone who uses
odd platforms (Ultrix, OpenBSD on (MIPS|Alpha|Sun|Apple), and
not Linux), I really hate the 1991 flashbacks of editting .h
files and Makefiles (or Perl's Configure).

  Autoconf does a lot of that work for us and leaves a nice
"config.h" that has the platform specific needs to work with.

  Let the user choose to disable TCP wrappers at an easily
reproduced "./configure" line.  Things like that.

  Recall that the common use of this is to build it and move on
with life for 6 months, a year whatever.  Then to come back and
try to figure out how we built it before when we need to
upgrade.  Me?  I keep around the ./configure lines in a build
area with the tar.gz files (EG: netatalk-1.4b2-configure, or
gzip-1.2.4-configure).

The hard work has been done with autoconf.  It's also an interface
admins are familiar with -- and for those of us who compiled OSS in the
late 80's and early 90's, one that we are grateful for.

Just my views,

chuck

---

From: John Barry <[email-masked]>
Date: Tue, 25 May 1999 22:04:45 +0200 (MET DST)

Hi,

> RPMs, since version skew is so rampant.

I compile stuff for a living, everything is difficult to build the first time.
Hands up those that built perl without trouble the first time? 

I like configure scripts they make the job far easier, if you want to tweak
something after the fact, simply alter the config.cache and run configure over
it again, easy.

"life before autoconf" is not something I like to contemplate on an empty
stomach :)

Having built netatalk before I found the build easy once you remembered to
turn everything off.

later
jb

---

From: [email-masked]
Date: Tue, 25 May 1999 16:13:29 -0400

> From:    John Barry <[email-masked]>
> To:      [email-masked]

> Hands up those that built perl without trouble the first time? 

I'll note this: the last "release" of netatalk I made was 1.4b2 -- a
beta.  It compiled pretty much cleanly and "out of the box" on all of
the platforms it was listed to work on.  I really don't think that's
asking for more than a little discipline on the part of the
developers.

And, ah, "show of hands"?  Good thing the whole world isn't run by
committee.

:wes

---

From: "Scott R. Every" <[email-masked]>
Date: Tue, 25 May 1999 16:16:19 -0400

I agree with chuck.  From the user POV(which is me) I would much rather
have a configure type interface.  Currently I have a 2 page doc that I keep
to remind me which files and options to change for netatalk based on what
machine I'm installing on.

I much prefer the Apache or mysql method where all(almost) of the options
can be selected via command line.

s

> late 80's and early 90's, one that we are grateful for.
<stuff deleted>

--
Scott R. Every - mailto:[email-masked]
EMJ Internet - http://www.emji.net
voice : 1-888-258-8959  fax : 1-919-363-4425

---

From: John Barry <[email-masked]>
Date: Tue, 25 May 1999 22:25:53 +0200 (MET DST)

Hi,

> asking for more than a little discipline on the part of the

Yup, he's right, compiled cleanly, installed without a hitch. Doesn't work
with appleshareIP.

Adrian's patches do, they required a little tweaking, both before and after
the fact, but I ran a lab of twenty macs from an aging sparc 2, and even got
them to spool to a lineprinter in the lab.

> And, ah, "show of hands"?  Good thing the whole world isn't run by

It is, we just didn't invite you :P

later
jb

---

From: Tim Carlson <[email-masked]>
Date: Tue, 25 May 1999 14:36:50 -0600 (MDT)

On Tue, 25 May 1999 [email-masked] wrote:

> the platforms it was listed to work on.  

Well I only compile for Solaris 2.5.1 and 2.7 anymore, but I can say that 
asun2.1.3 compiled out of the box for 2.7 32bit and asun2.1.4-17 compiled
out of the box for Solaris 2.7 64bit and 32bit

Where "out of the box" means doing the correct things as they are plainly
marked in sys/solaris/Makefile.

I'd personally rather see the new features before ease of compiling.. of
course i have compiled netatalk a couple dozen times so that helps..
Hell, it still beats compiling CAP :)

I'm sure we could get into a glorious argument over what should and should
not be easy. :) I'm actually ecstatic that asun2.1.4-17 works as
advertised. 

Tim

---

From: a sun <[email-masked]>
Date: Tue, 25 May 1999 13:34:50 -0700 (PDT)

when i go to a new system, i just turn off all of the options and then
turn them on as i build the various bits. many of the features are
optional on any system. i don't know how you handle that with a global
Makefile. here's what i see:

	1) DESDIR/CRYPTODIR: optional on any system. it's really
           useful though if you want reasonably secure
           authentication. 

	2) PAM: doesn't work with solaris for some unknown reason
	   related with session management, but it might work in the
	   future. it works with linux, but not all distributions use
	   pam. pam is also a separate package that can be installed
	   on other systems.

        3) TCPWRAPDIR: installed by default on *bsd/linux
           systems. optional on others.

        4) CRACKDIR: installed with redhat linux. optional on other
           systems (i've been beefing up the password stuff lately).

	5) DB2DIR: currently unused, but it will become mandatory in
           the future. it's installed by default on the recent *bsds
           and in glibc 2.1 systems.

these could all be checked/asked for pretty easily. i can just as
easily turn them all off, but then people start complaining about
"missing" features. 

then's there are all of the system specific bits:
        1) linux: there are a bunch of defines in sys/linux to handle
	          various broken bits and different library/kernel
		  versions. some distributions need -lcrypt while
		  others don't. ditto for -lrpcsvc and -lresolv. mondo
		  yucko.
		  
        2) solaris: solaris 2.5.1, 2.6, and 7 (nee 2.7) all do things
           slightly differently. i've simplified what defines need to
           get passed for things to work, but the default (for solaris
           7) breaks on solaris 2.5.1. 

	3) *bsd: they suffer from some version skew as well.

        3) sys/generic. There are a whole host of different defines
           that are useable for porting. it's currently setup for os x
           server. i suppose i could just move the os x server defines
           into a sys/osxserver directory, but that still leaves all
           of the afpd-only other platforms. 

part of this is solvable via uname -r/-m being passed in as
OSVERSION/MACHINETYPE, but the other bits aren't detectable in that
fashion.

okay. i didn't realize that that was the plan. i've done a bunch of
stuff for afpd during my attempt to get things to compile on random
oses. the pap stuff, however, needs serious work. that said, i don't
have a lot of time to go through the parts of the code that i don't
touch much right now or to test all the random platforms/os versions
that exist. i have ready access to several redhat linux 5.2-based
machines and os x server, but that's about all. 

and then there's that dissertation ...

-a

---

From: chuck <[email-masked]>
Date: Tue, 25 May 1999 15:22:13 -0700

I'm an SA, not a much of a developer (and worse, an SA who hasn't
written an autoconf anything since it pretty much first appeared),
so I am leaping backwards from the volunteer line on this.

So in a kibitzing role only, it makes sense to figure out with a
yeah/nay whether each of these features below are implemented on the
platform.  Let the command line override it. This is useful when a
feature might be 'unexpected' for the paltform.  eg: PAM also is
present on FreeBSD 3.1 and 3.2 in some form and will hopefully start to
appear on the other BSDs soon, so '--with-pam[=/usr/lib/libpam.a]'.
Anyhow, I run fairly standard userland on all my machines (tcpd, gnu
utils, etc) because I got sick of "df" being different on each of 12
architectures I had to deal with.

Does PERL's 'Configure' work?  Not really.  Half the time, I get a
login to a new machine and have little clue about it.  "Is it Big
Endian or Little Endian?"  Damned if I know, you're the computer,
figure it out.

GNU autoconf does much better at testing these things.

The hardest part will be getting the netatalk source into a series
of "ifdefs" that comply with the autoconf output.

And finally, yeah, it would be nice to have a non-beta version of
netatalk, if only to stop scaring the managers who don't see that a
product that's been in beta for 2 years is going to be fairly stable.

So once it's under autoconf control (not a minor effort, but hopefully
easier than Appletalk/IP), then it should be easier to add new ports,
because the structure will be inherently broken out a bit more.
(Wouldn't it be cool to have a unified release once again?)

I can't say I'm intimate with the current state of the sources with the
patches du jour, I run it on a smallish network where it does basic
file services for Macs and printing for Unix boxes onto Appletalk
printers.  I don't push it that hard, it doesn't fight.  It runs.  It's
run for a couple years.  That's about the best this you can say about a
piece of software.

And theses come and go, this will make you a legend!   :)

chuck

>            7) breaks on solaris 2.5.1. 

2.6 fixed a bunch of things in 2.5.1.  2.4 is not worth using (and I
consider it the last Beta of Solaris; still a dog).

---

From: a sun <[email-masked]>
Date: Tue, 25 May 1999 13:34:50 -0700 (PDT)

-a

---

From: Patrik Schindler <[email-masked]>
Date: Tue, 25 May 1999 23:55:41 +0200

>It is, we just didn't invite you :P

This list is not the place to flame anyone. Bringing netatalk to the state what it is today is hard work. That is something a normal user (no coder) should always remember.

:wq! PoC

I'm learning to code. I *IS* hard work.

---

From: a sun <[email-masked]>
Date: Tue, 25 May 1999 15:52:22 -0700 (PDT)

here's my statement:

send me a patch to my stuff that uses autoconf, and i'll incorporate
it. i don't have time to do it myself right now. if i don't get
anything, then you'll have to wait for some undetermined time until it
does get done. actually, you can apply that statement to any desired
feature that i'm not currently working on. 

for hints on things to think about, look in sys/generic/Makefile. i've
already pulled a lot of the system-specific things into #defines. in
addition, there are a couple first-cut defines that essentially turn
off lots of stuff for new machines.

actually, i'm pretty excited about mine. it has the potential to cause
a stir in the field of community ecology. if i had wanted to be a
legend, i wouldn't be working on netatalk. the use of appleshare isn't
widespread enough. gruntwork, while necessary, isn't usually the stuff
of legends. besides, don't you usually have to be dead to be a legend?

-a

---

From: Sak Wathanasin <[email-masked]>
Date: Wed, 26 May 1999 22:25:22 +0100

In reply to a sun's message of the 25/05/99 at 15:52 -0700,

> of legends. besides, don't you usually have to be dead to be a legend?

No you can be a legend in your lifetime. Isn't there some annual Apple award
for contributions to Internet freeware? Perhaps this list could show its
appreciation by nominating both Adrian and Wesley (jointly) for this...
Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [email-masked]
Phone: (+44) 1203 419996                    Fax: (+44) 1203 690690