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

[Mark Dufour]

hi all,

sorry if I send this double, as I'm not sure everyone is on pkg-giraffe-discuss.

I've been talking to management, our lawyer and the z-push people, and everyone agrees we can and would like to enable more liberal use of the z-push trademark, similar to what we did for the zarafa/kopano trademark earlier. there are some details to work out obviously, but I don't see any obstacles to this occurring in the near future.


cheers,
mark.

 
 
-----Original message-----
> From:Guido Günther <agx at sigxcpu.org>
> Sent: Tuesday 25th October 2016 9:56
> To: Sebastian Kummer <s.kummer at kopano.com>
> Cc: Felix Bartels <f.bartels at kopano.com>; pkg-giraffe-discuss at lists.alioth.debian.org; 'Wolfram Quester' <wolfi at sigxcpu.org>; 'Carsten Schoenert' <c.schoenert at t-online.de>
> Subject: Re: [Pkg-giraffe-discuss] Update von d-push/z-push in Debian testing?
> 
> 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
> 
> 
> _______________________________________________
> Pkg-giraffe-discuss mailing list
> Pkg-giraffe-discuss at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-giraffe-discuss
>