OpenPKG 2.5 was: [Kolab-devel] Freeze going for server 2.1.0beta

[Bernhard Reiter]

Am Sonntag, 27. November 2005 15:22 schrieb Martin Konold:
> Am Dienstag, 22. November 2005 11:14 schrieb Bernhard Reiter:
> > About OpenPKG 2.5: We believe this is a 4 to 5 days worth of work,
> > but this is a place non-key developers can help:
> > Try OpenPKG 2.5 on your platform, especially the packages that Kolab
> > Server will use. Next try to integrate the patches and then build Kolab
> > Server packages.
>
> I had a look at OpenPKG 2.5 and it installed fine on my SUSE and Debian
> systems.
>
> OpenPKG 2.5 is important for Kolab 2.1 because of:
>
> - support of gcc 4 (this will help us for all those users having recent
> Linux distributions like RH AS 4, Fedora Core 4, FreeBSD 6.0 and SUSE 10.
> Users of these platforms _cannot_ use OpenPKG 2.4.x!!) The number of users
> running these platforms is increasing on a daily basis.

Can you give more details why they cannot use OpenPKG 2.4.X?

> - OpenPKG 2.5 is longer supported in the future compared to OpenPKG 2.4.x.
>
> - It needs to be determined what the switch to SMF (Service Management
> Facility) will mean to Kolab.

AFAIU this is only on Solaris 10.

> - The state of the current integration of the Kolab changes to OpenPKG
> packages is unknown to me. Thomas: Can you provide some insight here.
>
> - The later can lead to a smaller Kolab distribution set and only requires
> in some cases Kolab specific switches to the creation of binary rpms.
>
> - The risks involved into switching to OpenPKG 2.5 now seem to me not very
> big and now is imho the best time to switch as at this time we have a hight
> chance to reach many testers. Especially the fact that we are opening Kolab
> to users of FC4 and SUSE10 will lead to many more testets.

Switching will be about 3-4 days of work.

Biggest risk is instability, especially on the openldap and Berkley DB side.
Note that we used the old Berkely db because OpenPKG and OpenLDAP
did not even answered our questions if the new one is reasonable stable.
When switching, we have the same question again.
What is your answer?

Another risk is time delay: A stable server with simple email-multidomain
is badly needed and the technology is there. Each week, we do not have it out,
costs us potential users.

Bernhard