[pkg-kolab] Re: State of debian packages?

Philip Hands phil at hands.com
Wed Mar 21 13:16:34 CET 2007

Hash: SHA1

Johannes Graumann wrote:
> I'd like to chime in here too ... I was trying A LOT to setup Kolab according 
> to the howto coming with the debs - must have been around 20 times or so ... 
> I even wrote a python script to exclude manual error from the process ... and 
> did never succeed in a way that would tell me "you succeeded". I ended up 
> switching to the openpkg distro in combination with debians nullmailer 
> package.

OK, so it seems I'm not alone in being unable to persuade myself that I've
succeeded in installing the pkg-kolab packages.

Given that we have people putting quite a bit of effort into installing
pkg-kolab (repeatedly), and still perceiving that they failed, I'd say that
you are seeing the tip of the iceberg, and that one can assume that there
are many more who have given up earlier, or who are not following this list.

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.  This will only get worse if the packages in
their current state are allowed into stable, since that will encourage more
people to try them, and they will be even more frustrated when they fail to
get it to work, so are liable to go and never come back.  Also, the
packages will be set in stone for the duration of the Etch's lifespan as

I was hoping that my mail would provoke someone into defending the current
state of the packages, or perhaps revealing that "Oh, yeah, we use our own
in-house LDIF file, so no wonder you didn't get anywhere" or even reply to
Johannes with "Oh, good point, we should add a note to the README saying
that you shouldn't expect ssled ldap in kolab, so don't think that just
because that's not there that you've failed in some way"

If anyone is willing to try and persuade me that pkg-kolab is not in the
broken state that several of us have concluded that it's in, fine, but
otherwise I think the right thing to do would be to file an RC bug to
ensure that it doesn't get released in etch so that at least people will be
able to grab it out of backports when some usable packages do turn up, and
won't in the mean time be confused by these packages and the assertion that
they are in some way "stable".

Having them in a state where the people that generated the package are able
to use them, but nobody else seems to be able to get anywhere without
considerable effort, is not good enough for entry into Debian stable IMO.

I'd imagine that it just needs as little as a couple of encouraging
comments to be added to the README, and maybe one or two minor tweaks to
the example LDIF, say, but I'm not sure because it's complicated enough to
overwhelm someone who is not already familiar with kolab.  In the longer
term, initial setup should really be done via debconf questions if
possible, so that users don't have to wonder if they've done it right or
not, and so that it's obvious that there is a bug to report if it doesn't
work out of the box.

Cheers, Phil.
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the pkg-kolab-devel mailing list