[Pkg-giraffe-discuss] How to proceed for d-push/z-push packaging?

[Carsten Schoenert]

On 27.12.2016 11:14, Roel van Meer wrote:
...
> The current plan is as follows:
> 
> - Base everything on the very useful work that Carsten already did in [1].
> 
> - Rename the source package to 'z-push', since we can do that now
>   d-push has been removed from unstable [2].

That's fine I think.

> - Add the z-push-autodiscover package. The contents of this package
>   might have been merged with the z-push-common package, but then I
>   would have liked to have an option in the autodiscover config with
>   which autodiscovery can be enabled or disabled. Since we don't have
>   that (and so there is no way to nicely disable autodiscovery if you
>   have the files installed), I think it's best to keep this in a
>   separate package for now.

Booth possibilities are o.k. for now.

> - Merge z-push-config-apache into z-push-common, and merge
>   z-push-config-apache-autodiscover into z-push-autodiscover. As
>   Carsten already said, we can just install config files for all
>   supported webservers, and let the postinst files do the right thing.
>   How this should be done is documented in [3].

Ack.

> - Merge z-push-ipc-sharedmemory into z-push-common. This package
>   contains only one file, has no external dependencies, and will be
>   used in most installs.

Ack.

> - If z-push-ipc-sharedmemory is merged with z-push-common, then the
>   z-push-kopano metapackage is not really useful anymore, as it does
>   nothing else but having a dependency on z-push-backend-kopano.
>   Therefore I would propose to remove this metapackage as well.
>   This also avoids confusion between the other backend packages
>   (all named z-push-backend-something) and this one.

Also ack. But then we should document elsewhere what a user needs to
install if they come from the Kopano side.

> - Build a package for *jessie*, and test that it works with the kopano
>   backend. (Why jessie? Because we're currently doing a lot of automated
>   testing on jessie, including Kopano and Z-push, and this way we can
>   reuse this effort for these z-push packages).

Hmm, I would start with unstable. And Jessie will become old-stable in a
few months. Stretch will stay much closer to the current testing for
some months. I would put my energy on bringing the Kopano packages into
testing first, and depending on that the Z-Push packages. If that is
working go further on bringing the upstream packages of Z-Push together
with Debian.

> - Install config files for lighttpd in the z-push-common package. We
>   need these if we ever want to support upgrading from current d-push
>   to new z-push packages, as d-push had support for lighttpd as well.
> 
> - Also install the nginx config files, just to be complete.

Yes, as done for Apache.

> - Test that we can go back and forth between the current Debian
>   packages provided by the Z-push repo and the new Debian builds. I
>   think this will be the commonest type of upgrade that might happen,
>   so it seems to be the logical one to start testing with.
> 
> - Then test upgrading d-push to z-push on jessie.

That are steps that I would do last. But that all are just my minds,
someone my think differ.
I mostly agree with you plan. I would so start so.

-- 
Regards
Carsten Schoenert