[Pkg-giraffe-discuss] zarafa-7.2.1 RC1 released

[Guido Günther]

Hi Mark,
thanks for looking into this!

On Mon, Sep 21, 2015 at 11:43:33AM +0200, Mark Dufour wrote:
[..snip..]
> > > Documentation in /usr/share/doc/zarafa
> > > ======================================
> > > The folder currently contains little documentation but lots of
> > > scripts. Iff we want to ship them they should go to
> > > /usr/share/doc/zarafa-server/examples but most of this is of little use
> > > to Debian users. All files need to be moved to
> > > /usr/share/doc/zarafa-server/ since that's the package that ships it.
> > > We can ship a symlink /u/s/doc/zarafa -> zarafa-server if wanted.
> > 
> > Not done yet. Patch for ths would be welcome.
> 
> yeah, I guess the scripts and example configs can just be left out. a symlink from zarafa to zarafa-server sounds fine for now, if the files really have to be in zarafa-server.

They should be. I'm not sure I can look into this before vac but it's
simple so most of us here should be able to fix it.

> 
> > > Manpages
> > > ========
> > > At least the zarafa-server manpages talks about license keys. I don't
> > > think that is applicable for the server (or is it)? If not we should
> > > remove it.
> > 
> > Not done yet. Patch for ths would be welcome.
> 
> I grepped through all man-pages, and it looks like zarafa-admin is the
> only other one that specifically mentions something with
> licensing. something like attached patch might be applied for now.

That looks sane. I add this one.

> 
> > > Handling of security updates
> > > ============================
> > > With the LTS team in Debian we now support packages for 5 years. It's
> > > always a pity if we have to end security support before that due to
> > > lack of upstream support. So I wonder: once we have a version in a
> > > Debian stable release will zarafa support the security team in
> > > backporting fixes to these versions?
> > 
> > We had a short discussion about that at the tour but I'm not sure what
> > the exact outcome was. Maybe you guys can pick this up in Hannover
> > again? Since you do have a CVE process making the patches that fixes the
> > CVEs available would be a great first step.
> 
> I'd certainly be happy to help, but as of now know little about this whole process. but I don't see why we couldn't share patches early with you.. 
> 
> > Public headers
> > ==============
> > While the zarafa-dev package ships the symlinkcs to the SOs it doesn't
> > ship any public headers. Looking at the header I couldn't find a clear
> > cut between public and private headers. Can you suggest what we should
> > move into the package. It would also be great to have a minimalistic
> 
> this is hard to say for me, I'm afraid. I seem to remember jan to be
> working on improving this (will ask him), but for now I don't think it
> would hurt to just ship it as is..? :S realistically, I don't think
> anyone will really develop against these though, but rather use
> something like python-zarafa (or something like libzarafa-simple as
> folkert mentioned at the tour, which would have a clear user
> interface).

Well, we just can't ship a non-functional dev package. That just makes
no sense and will be (rightfully) a source of frustration for people
installing it. We can drop the dev package but if we do that having 7
split out libraries packages really makes no sense anymore if _nobody_
can use them separately. So I see two ways out of this:

1.) _either_ merge all shared objects (private or not) into a
  zarafa-libs and make it clear that this is a purely internal
  dependency (from the package description)
2.) _or_ fix up the public headers so people can develop against it.

I would prefer 2.) but if 1.) is quicker we can go that route until
7.2.2 but then again I can't do this soonish so somebody would need
to pick this up. The pattern would be pretty much the same as in
26fce433bfbaf7cd9fefa80148d5c742cc1ba481.

So any takers to get these resolved?

Cheers,
 -- Guido