[Pkg-giraffe-discuss] zarafa-7.2.1 RC1 released
Carsten Schoenert
c.schoenert at t-online.de
Sun Sep 13 08:44:31 UTC 2015
Hello Guido,
thanks for working on this and brings the points up!
Am 12.09.2015 um 21:46 schrieb Guido Günther:
>> Yeah, from what I've seen we're mostly set for an upload to
>> experimental. The single thing we should beforehand is letting
>> the daemon run as a regular user than root. I'll try to find
>> the time to tackle this with Carsten during debconf.
>
> While none of these are really, really bad we should consider cleaning
> them up before we upload the first time:
>
> Libraries
> =========
>
> $ grep "Package: lib" debian/control | wc -l
> 14
>
> That's a lot for a groupware. I wonder if we couldn't just bundle them
> in one library package for the time being? Especially things like
> libzcp_common_ssl seem to only have one single class:
>
> # objdump -w --dynamic-syms /usr/lib/libzcp_common_ssl.so.0.0.0 | grep " g "| grep ECC | wc -l
> 33
>
> Bundling things would certainly make the ftp-masters happy. We could
> also split into three: client, server and common. Opinions?
Yes, this already comes up while Debconf. I fully agree here, not only
to make the FTP guys happy, but to tear down also complexity for us too.
The package count at all should be small as possible.
I tried to collect manually the dependencies of the virtual zarafa
package and also on the libraries. It's a complex thing. ;) See attached
txt file.
In short, the user will surly install the package 'zarafa' at minimum
and that brings currently the following dependencies for the libraries
(if I collect the most correctly).
There is a minimal need for the following libraries every time:
libicalmapi1
libmapi1
libzarafa-archiver0
libzcp-common-mapi0
libzcp-common-util0
Back to the question, if possible I would just package two library
packages, one for the common things (libzvp-common-*, libicalmapi1,
libmapi1) and the private libraries in /usr/lib/zarafa/*.so, and
everything else in a libzarafa-extra package.
The advice of Guido is also usable, but for me there is no big
difference between common and server as a server instance is normally
always needed. But maybe there are reasons there the user needs a bigger
server setup of installation because for performance reasons or for
redundancy. That's a think Mark can answer better I think.
> Recommends
> ==========
> * We currently only suggest a database server so it doesn't get pulled in
> when doing a "apt-get install zarafa-server"
> I think we should recommend mariadb-server so the user gets a working
> installation. If he doesn't want it he an always install without it or
> move it to a different server later. If there's agreement I'll fix this
> in git.
As from the point we don't really now what the future will bring for
MySQL packages I would like to suggest or as you wrote recommend mariadb
packages.
Right now the mariadb-server lacks a debconf setup for creating the root
user like the mysql-server does! I opened up a bug because of this. But
the reaction of Otto wasn't there helpful until yet. The user has
currently first setup a root user for mariadb-server before continuing
installing Zarafa. So we should the user give a advice while
installation of the zarafa package. Currently I haven't a good idea how
to do so. Maybe with debconf ...
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=797210
> * We don't recommend zarafa-webapp either. o.k. to add this as
> Recommends to the zarafa package? (until we have the webapp in the
> archive and then make it a dependency).
>
> Any opnions on this one?
If we can't upload the zarafa-webapp package first then this should be
the way.
[snip]
> Documentation in /usr/share/doc/zarafa
> ======================================
> The folder currently contains little documentation but lots of
> scripts. If 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.
I worked yesterday on some parts of this and was also thinking about
moving all that stuff to zarafa-server. But yes, as longer I'm thinking
about that I tend to say yes, that's how we should handle this.
And I think there should be a minimal howto as text file that explains
what a user must do after the installation.
In the end there should be also a bigger documentation as a PDF/HTML
file like it is available online. But some installations are in a
restricted area and there is no easy way to get online and pull a more
detailed documentation from the internet.
> 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?
Interesting and importand question! :)
Just for clarification, fixes for a version doesn't mean "Please upgrade
from 7.2.1 to 7.2.". So it's a good plan to think about it before. As
Guido wrote that backporting security fixes can be a messy and time
consuming thing. Not only to figure out how a rewritten file adopt to
old things, it's sometimes also getting non public information for
preparation of fixes. I think Zarafa has surly the same problems as most
users not switch every two years their versions and working normaly with
"old" versions.
> zarafa-search
> =============
> If there are issues running as non root in 7.2.1 should we skip it for
> the initial upload. We can easily readd it once the dust has settled
> (once we're through the NEW queue).
>
>
> I'd be happy to pick up on these tasks but wanted to check first if
> anybody does similar stuff and get agreement on the library split.
>
> I'm sure some more things will pop up when doing further testing but I
> think we're almost there for zcp.
I'm not that deep in the internal relationships between the zarafa
components like Guido. We should use the upcoming event in Amsterdam to
coordinate in face to face talks what priorities are needed to get
further in a effective way. My time for complex things (like
restructures) is limited, I mainly only can do such work on the weekend.
But I think Guido and Matthias has the same problem. ;) But yeah, we are
short steps before finishing.
--
Regards
Carsten Schoenert
-------------- next part --------------
Dependencies Package Zarafa:
zarafa:
zarafa-server
zarafa-common
zarafa-client
libmapi1,
zarafa-lang
zarafa-client
libmapi1
zarafa-lang
libmapi1
zarafa-utils,
zarafa-client
libzarafa-archiver0
zarafa-monitor,
zarafa-common
zarafa-client
libmapi1,
zarafa-lang
zarafa-client
libmapi1
zarafa-lang
libmapi1
php5-mapi
zarafa-client
libmapi1,
zarafa-lang
zarafa-client
libmapi1
zarafa-lang
python-mapi
zarafa-client
libmapi1,
zarafa-lang
zarafa-client
libmapi1
zarafa-lang
zarafa-spooler,
zarafa-common
zarafa-client
libmapi1,
zarafa-lang
zarafa-client
libmapi1
zarafa-lang
libicalmapi1
python-mapi
zarafa-client
libmapi1,
zarafa-lang
zarafa-client
libmapi1
zarafa-lang
zarafa-dagent,
zarafa-common
zarafa-client
libmapi1,
zarafa-lang
zarafa-client
libmapi1
zarafa-lang
libmapi1
php5-mapi
zarafa-client
libmapi1,
zarafa-lang
zarafa-client
libmapi1
zarafa-lang
python-mapi
zarafa-client
libmapi1,
zarafa-lang
zarafa-client
libmapi1
zarafa-lang
zarafa-ical,
zarafa-common
zarafa-client
libmapi1,
zarafa-lang
zarafa-client
libmapi1
zarafa-lang
libmapi1
zarafa-gateway,
zarafa-common
zarafa-client
libmapi1,
zarafa-lang
zarafa-client
libmapi1
zarafa-lang
libmapi1
zarafa-search-plus,
zarafa-common
Dependencies Libraries:
libfreebusy0
libmapi1
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-util0
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-util0
libicalmapi1 <- needed by Package Zarafa
libmapi1
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-util0
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-util0
libinetmapi1
libicalmapi1 <- needed by Package Zarafa
libmapi1
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-util0
libzcp-common-mapi0
libzcp-common-util0
libmapi1
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-util0
libmapi1 <- needed by Package Zarafa
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-util0
libzarafa-archiver0 <- needed by Package Zarafa
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-util0
libmapi1
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-util0
libzarafa-archiver-core0
libmapi1
libzarafa-archiver0
libzcp-common-mapi0
libzcp-common-util0
libmapi1
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-service0
libzcp-common-util0
libzarafa-server0
libzarafa-soapclient0
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-ssl0
libzcp-common-util0
libzcp-common-util0
libzarafa-soapclient0
libzarafa-soapserver0
libzarafasync0
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-mapi0
libzcp-common-util0
libzcp-common-service0
libzcp-common-util0
libzcp-common-ssl0
libzcp-common-util0
libzcp-common-util0
More information about the Pkg-giraffe-discuss
mailing list