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
Quoting a sun ([EMAIL PROTECTED]):
> 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.
>
> 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.
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).
> 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.
