.info and .deb validated. compiled and tested with Darwin 8.3.0
tree: 10.4 ; category=libs
Logged In: YES
This thing compiles cleanly, but there are some dependency
configure: WARNING: GnuTLS support disabled.
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
checking for main in -lrsaref... no
checking for main in -lcrypto... yes
checking for SSL_library_init in -lssl... yes
checking sasl/sasl.h usability... yes
checking sasl/sasl.h presence... yes
checking for sasl/sasl.h... yes
checking for sasl_client_init in -lsasl2... yes
so you need to either have Depends/BuildDepends to make sure
that these support libs and/or headers are always present or
else force the configure tests to fail to detect them even
if they are present. Goal: everyone gets the same build
There are also tests for libiconv. Interestingly, according
to 'otool -L', the .dylib is not linked against libiconv,
but nm reports unresolved libiconv symbols in it. That means
packages that want to link against your lib will have
difficulty gussing the correct flags to use. Sounds like
there's a missing -liconv during the linking stage...bug in
There are also tests for db.h and a db lib. Again, need some
deps and there's probably a missing -l flag.
Shared-library packages can be tricky to package. Right now,
you have headers and other compile-time stuff as well as and
runtime libs all in one package that is marked
BuildDependsOnly:true. That means another package that uses
this one will not be able to Depends on it (that would be a
BDO violation) but it would need to access those shared
library files at runtime (i.e., list it as Depends). There's
a chapter about our official Shared Libary Policy in the
Packaging Manual, and there are the beginnings of a
Shlibs-packages tutorial on the wiki:
Logged In: YES
SSL and SASL are quite essential to me so that's a very valid point. I've
decided to force the GnuTLS support too since this package is well
maintained in Fink... might be useful to others.
the shared lib aspect is a hard nut to crack for me so it might be a while
until I upload a info files that addresses this. thanks for the link and most
importantly your time.
OK this is a foolish attempt at wrapping this one up or rather a request
for further comments.
I worked my way through the doc but possibly more than I can chew in
otool -L shows a link to libiconv here btw.
Interestingly I tested configure --disable-iconv and it still links the dylib
to libiconv as far as I can tell so this may add weight to the bug in
upstream. I'm confused all the same.
Logged In: YES
This looks pretty good.
Looks like there's a leftover depend on openssl?
A minor nitpick: Fields should be wrapped at 80 characters.
This is a personal preference of mine, feel free to ignore it.
Also, FYI: because this package links to libs in crypto,
this must also go into crypto.
thanks for that Corey. you mean a runtime Dep in the splitoff
presumably... I'll have a look.
there are a couple of things that I just blagged (based on your gnutls
package) but if you could explain the following it probably will help me in
the long run:
%p/lib/libetpan.3.2.0.dylib 4.0.0 %n (>= 3.2.0-1)
the 4.0.0 in particular was chosen arbitrarily to get the ball rolling but I'm
not sure what it should correspond to. Feel free to refer me to some doc,
I've not read anything on that yet but I'm sure it's out there.