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

[Guido Günther]

Hi Sebastian,
(these are just ideas, I'll leave the decisions to the prospective
maintainers):

On Mon, Oct 24, 2016 at 08:56:14PM +0200, Sebastian Kummer wrote:
> Hi,
> 
> >> z-push-config-apache
> >> z-push-config-apache-autodiscover
> >> z-push-ipc-memcached
> >> z-push-ipc-sharedmemory
> >These 4 look like they could be handled via proper dependencies and
> >guessing defaults.
> 
> I had a look on how e.g. phpmyadmin does that. So you basically put your
> apache config in /etc/z-push/apache.conf and then symlink in postinst to
> /etc/apache2/conf-available. This way you basically distribute the configs
> for all supported webservers and link depending on the existing
> configuration. Did I get this right?
> What happens if you have more than one webserver installed (I've seen this
> on several systems already)?
> Which one should be used? Or would we simply leave it unconfigured in such a
> case?

You can drop in configuration for several webservers. The one thats
running picks it up. (i.e. by adding a vhost thats restricted to port
443 and using a include or a symlink as you describe above).

> Idea of our package layout was to have maximum flexibility and not to force
> the user to install code he will never need or use.
> This is why the backends are separated and the ipc-backends fall into the
> same principle.
> For small(er) environments shared-memory is most indicated, with a few 100
> users memcache wins in terms of performance.
> Both fully replace one-another and it depends on your individual needs.
> Still, for most cases shared-memory would be fine.

So why not include the shared-memory backend in the default package and
add the memcache backend as an extra package? This way the user would
get a nice default configuration and would switch to memcached
automatically once installed.

> As Felix already pointed out, we would very much like that the packages are
> consistent, to avoid user confusion and allow easy migrations. E.g. on RHEL
> and OpenSUSE we want separated shared-memory packages, because there
> sysvshm/sysvsem are not compiled into php by default, so these are a
> dependency there.

This is understandable from an upstream point of view on the Debian side
we'd rather see the package _integrated_ into the distribution (using
the provided tools (debconf, db-config-common, ...)) so things get the
same look and feel and degree of automation. Since these things differ
between distributions the packages can't stay identical in the long
run.

Cheers,
 -- Guido