[Pkg-giraffe-discuss] Update von d-push/z-push in Debian testing?

[Carsten Schoenert]

Hello Felix,

On 24.10.2016 11:28, Felix Bartels wrote:
> As far as I can see the package layout you are speaking about was
> only used in the unreleased Z-Push 2.1 update, but not in the
> currently distributed packages (as can be seen here
> https://packages.debian.org/search?keywords=d-push&searchon=names&suite=all&section=all).
> Is it then still necessary to have transition packages for this
> layout?

yes and no. :-)
The Debian packages I was speaking are the packages that would be
created by the latest update and upload within the Debian git packaging
tree. That was done by Wolfram in February 2013 right after the upload
of 2.0.7-1, and yes, that would be version 2.1.0 [1].
That's of course far away from the current needs and provided packages
by Zarafa/Kopano.

And version 2.0.7-1 is the used version in Jessie we have to take care
of that. And even more. If we want to meld the Debian packages from
Zarafa/Kopano we need to take more care.
But that's not a real big problem, that's why there are fields like
Depends, Provides, Replaces and Breaks. We "only" need to collect the
needed packages and version dependencies to fill there.

> A development writeup about the z-push provided packaging can be
> found on https://wiki.z-hub.io/display/ZP/Packages and
> https://wiki.z-hub.io/display/ZP/Installation. This also mentions
> that the packages you are missing in your overview are now
> unsupported and therefore no packages are built for them.

Thanks, I haven't noted this yet. That's helpful.

> While we designed the package layout how we see it fit, we are more
> than open for feedback and suggestions on how to make this easier to
> comprehend for admins. Imho the main goal should be to have both
> packaged builds mirror each other closely, so that users could easily
> switch from one to the other.

I would go one step further. There should be only one place for the
packages. If you are familar with the main tool we use -
git-buildpackage - you will see the enormous flexibility given by that.

> The goal of this package layout on the other hand was to give admins
> the possibility to install only the packages they really need. Z-Push
> 2.3 for example introduced the possibility to have volatile states
> (used for loop detection) in memcache instead of using php
> shared-memory (which is still the default if both are installed).
> This reflects in on package z-push-ipc-sharedmemory (in your example
> this would have been part of d-push-common) and one dedicated
> z-push-ipc-memcached.

As written, I would tear down the amount of packages. But that should
depend in the end on the maintainers of the packages. We will see what's
best.

> Having multiple config packages for webserver configuration seemed
> for us the easiest approach to satisfy the need to support multiple
> webservers (without directly supplying configuration examples for all
> these servers).

I was thinking the same in days before I've done some packaging on that.
My minds have changed on this as I've see the great possibilities given
the mechanisms of apt/dpkg.

For example a admin can control the preferred webserver to use even if
z-push would use for example a

Depends: apache2 | nginx | lighttp| http

Simply install the desired webserver by

  apt install nginx z-push

That would install ngix instead of apache2, even as the first line in
the Depends field is Apache2. Just put all configuration files for the
webserver into the package and install them into the right place.
By this there is no need for three config packages.

[1] https://anonscm.debian.org/cgit/pkg-giraffe/d-push.git/log/

-- 
Regards
Carsten Schoenert