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

[Mathieu Parent]

2009/1/5 Jürgen Büchs <Juergen.Buechs at gmx.de>:
> Hello Mathieu,
>
> thanks for your answers first.
You're welcome
>
> (snip)
>
>> > 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.

Maybe you can first ask on IRC, then post a mail to debian-release. I
won't disallow you...

>> 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).

OK. I will then add lenny-backport (once it is created). These are
safer than apt-pinning.

>
>> > 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.

I'm not that experienced debian user, but as it was difficult to
unblock some other packages (see debian-release archive) ...

>
>> > 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.

There is a difference :
freeze: http://release.debian.org/emails/release-update-200808
 A new version may only contain changes falling in one of the
 following categories (compared to the version in testing):
  - fixes for release critical bugs (i.e., bugs of severity critical,
    grave, and serious) in all packages;
  - changes for release goals, if they are not invasive;
  - fixes for severity: important bugs in packages of priority: optional
    or extra, only when this can be done via unstable;
  - translation updates
  - documentation fixes


deep-freeze : http://lists.debian.org/debian-devel-announce/2008/12/msg00006.html
    * unblock requests sent after d-i RC2 will only be considered if
      they fix RC bugs, and nothing else.

>
>> 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.

Going to openpkg is not a good solution as there is no migration path.
Same for other distributions.
Wait some time and there will be backports of 2.2.0 (or maybe 2.2.1).
This is safe, and upgrade migration has been tested. You will also be
ready for squeeze (lenny+1).


>
>>(snip)
>
> Regards
>
>
> Jürgen Büchs
>

Regards

Mathieu Parent