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

[Carsten Schoenert]

Hi,

I removing Guido and Wolfram from CC as they are subscribed to the list
either.

Am 24.10.2016 um 20:56 schrieb Sebastian Kummer:
> 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?

Yes, that is 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?

Not really, for kopano-webapp I was preparing the configuration in the
respective folders like conf-available/ for Apache. So in the end the
webserver configurations are placed in the folders the webserver is
searching or the user has to copy from. A other typical thing is to put
such files in /usr/share/doc/[package]/[apache,nginx,...] and let the
user copy the configuration into place.

But the usage of two different webserver on one host is more a unlikely
situation and the user needs to tweak the configuration manually at all.

I'd like to minimize the package list as much as possible, less is more
here I think. The more packages around the more knowledge is needed for
booth sides to do the right things to get a proper user experience.

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

That's o.k. if the complexity is not greater than the gain. The packages
are rather small and there are mechanism like updates-defaults or
reconfigure to handle the functionality of binaries or packages that can
do the same.

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

I haven't understand the use case for all of the packages you currently
create in the OBS so I can't say much about them right now. Probably
other people are deeper and have a better knowledge in that stuff and
willing to explain what's the best here.

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

I understand that position. On the other hand I don't want to take much
care for RHEL or CentOS.
In the end the best would be in my eyes if Kopano/Zarafa can drop their
need to provide Debian/Ubuntu package by themself and place the energy
in maintaining them directly in Debian. By this all down streams would
benefit directly without the need to handle package repositories and
explanation how to integrate them.

I'm not sure if we can handle all things until January next year (there
is the freeze) to provide new z-push packages. Not that's not possibly
technically, for me it's more a time problem to (co)work enough on the
packages.

-- 
Regards
Carsten Schoenert