[pkg-kolab] Re: State of debian packages?
phil at hands.com
Wed Mar 21 16:54:24 CET 2007
-----BEGIN PGP SIGNED MESSAGE-----
Peter Eisentraut wrote:
> Am Mittwoch, 21. März 2007 13:16 schrieb Philip Hands:
>> If that's the case then the current state of the packages appears to be
>> causing you to haemorrhage potential kolab users, and so potential bug
>> reporters and contributors.
> I can only repeat, if you have a grudge, make a concrete statement and file a
I have no grudge -- I've just done several from-scratch installs, following
the recipe in the README.Debian, and ended up with a system that doesn't work.
It's not _that_ far from working at that point as it turns out, and my most
recent attempt appears to be working after some random prodding of the LDAP
setup, but it took me a _long_ time to work out the precise prodding
required, and I'm not certain how much of what I did was really necessary,
nor if what I have now is really properly running.
I really don't think it's fair to allow others to go through the same pain.
If I'd been less stubborn I'd have given up long ago, rather than rummaging
through mailing lists, kolab upstream svn, and various other places
searching for inspiration.
That is not what one expects from a package that claims to be part of a
stable Debian release, and is a package of the stable upstream version.
> Certainly the packages are not all that easy to use, but that wasn't
> really the point when we moved away from openpkg. The point was easier
> maintenance of running systems. We have experimented with bootstrapping
> scripts several times, but that really didn't appear to be any better
Am I to understand you to mean that the packages are really aimed at people
already familiar with kolab? If that's the case then the README needs
prominent health warnings on it, and so probably does the package description.
Even so, that still doesn't strike me as being what I'd call "stable".
I'm happy to try to determine what it was that's missing from the README,
but it's not the individual issues that are actually the problem, since I
think they're all pretty trivial -- the problem is that the whole is
complex enough so that if the examples don't allow one to get to a working
install then you're stuck with a totally evil learning curve, and if you
ever manage to overcome that you're left with the sneaking suspicion that
if the people who packaged the thing failed to mention the issues you've
found, then how many others did they forget that you're yet to find.
As for a concrete statement, I'm pretty sure that the thing that stopped
local delivery from working was the setting slapcat.example.com.gz:
which it seems doesn't work because postfix doesn't expand the values it
finds in LDAP, so should instead be:
Trivial, of course, except that in order to find that I ended up having to
set up an OpenPKG install on another machine and compare what it ended up
with in it's LDAP database. If there had been a notice in the README
saying "Don't bother using these packages until you've successfully set up
an OpenPKG version of kolab" then I would at least have known what I was up
Now, if the only thing that's wrong is that minor thing in the example
file, then fine, but I've ended up (perhaps wrongly) with the impression
that that is not the only thing that's wrong.
That lack of confidence would perhaps be rectified if people were saying
"don't worry about that, I just tweaked the LDAP and have been using it
successfully for months", but I've not yet heard that here. I find it
somewhat suspicious that nobody else has noticed the problems -- it makes
me think that the people doing the packaging have not actually tried
following their own setup recipe to see if it really works.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the pkg-kolab-devel