[pkg-kolab] no Kolab in Debian testing/Lenny?

Jürgen Büchs Juergen.Buechs at gmx.de
Mon Jan 5 13:21:22 UTC 2009


Hello Mathieu,

thanks for your answers first.

Am Sonntag, 4. Januar 2009 16:56 schrieb Mathieu Parent:
> hi,
>
> 2009/1/3 Jürgen Büchs <Juergen.Buechs at gmx.de>:
> > Hallo all,
> >
> > I've just recognized that there is no kolabd package in Debian testing.
> > There's only version 1.9.4 in stable and 2.2.0 in unstable.
>
> Yes, kolab won't be in lenny (more info here:
> http://lists.debian.org/debian-release/2008/09/msg01211.html).

I've read the mails and I regret that no Kolab version will be in Lenny. Also 
looking to the work you have done - thanks for that.

> > So my question is:
> > What will happen, when Lenny is released and I will upgrade my server?
> >
> > Will the old Etch version stay on the server or will it be removed?
> > Shoudn't there be at least the old version included in Lenny?
>
> The old version will stay on the server. But it won't work because
> slapd in lenny is version 2.4 that doesn't include slurpd replication.
> And Kolab lower than 2.2 requires slurpd.

So this looks like a RC bug to me as an existing package would be broken when 
upgrading to Lenny. So in my opinion, it should be either an LDAP or a Kolab 
bug. But as you requested, I won't open a ticket for that.

> > Or is it an option to ask for an "unblock request" for all the kolab
> > packages to bring 2.2.0 into testing as there are no RC bugs?
>
> I think you shouldn't do this, we want to release lenny! Don't bother
> the release team with unblock requests.
>
> Unblocking kolab requires unblocking libnet-ldap-perl which is a major
> package with lots (33) packages depending on it. The release team
> won't accept that.

I've missed that dependencies.

> The current right way to use 2.2 is to do apt-pinning
> (http://www.argon.org/~roderick/apt-pinning.html) for *kolab* and
> libnet-ldap-perl unstable packages.

I'm running Kolab on a productive server, so I would use only stable packages. 
I don't accept mixing stable, testing or even unstable packages on a 
productive server. Therefore apt-pinning is not an option to me (if I 
understand apt-pinning correctly).

> > Looking to the Debian PTS, it seems to me that 2.1.0 was already in
> > testing, but removed on 2008-10-02. Also 2.2.0 was not added, as 2.1.0
> > was removed before. PTS tells that the package has to be added, not
> > updated.
>
> It was removed as requested in the thread
> http://lists.debian.org/debian-release/2008/09/msg01211.html. The
> packages were not uploaded before the freeze. This is the rule and
> kolab is not such a major package that justify to ignore the rule (see
> the rules here:
> http://release.debian.org/emails/release-update-200808).
>
> > Please tell me also, if I should open a ticket for this in BTS.
>
> Nope ;)

You are more experienced in Debian package management and know the rules 
better than me. So I accept your decision.

> > As the deep freeze is coming soon we should act immediatelly, if
> > something has to be done.
>
> We are already in freeze. And the rules deny us already to do anything
> for lenny.

I thought that there may be a difference between "freeze" and "deep freeze". 
But as I'm not a package maintainer - only a "user", I don't know the exact 
rules.

> To conclude, we missed the target for several reasons IMHO:
> - it was not possible to keep 1.9.4 because slurpd was not in lenny
> - 2.2.0 was released (July 11th) just before the freeze (July 27th),
> - I had to add syncrepl support to kolab
> (https://www.intevation.de/roundup/kolab/issue1755, first version mid
> June, landed just after 2.2.0)
> - we needed horde 3.2 which was released/uploaded just before the
> freeze (2008-06-18)
> - I'm not (yet) a DD, so this takes some time to upload new versions.
>
> So it was near-to-unreachable as all those prerequisites were done
> just before the freeze.
>
> To reduce the impact, I encourage to use apt-pinning (backport is IMO
> not needed as these are not compiled in packages).

I won't use apt-pinning. Maybe I will use Lenny and the binary openpkg Kolab 
version directly from www.kolab.org or migrate to another Linux destribution 
for my servers. I'll have to investigate what's the right way for me.

> > Best regards
> >
> >
> > Jürgen Büchs
>
> Regards
>
> Mathieu Parent

Regards


Jürgen Büchs



More information about the pkg-kolab-devel mailing list