[Pkg-giraffe-discuss] Try out to package kopano-webapp-plugin-files* fails

[Carsten Schoenert]

Hello Jelle,

On 16.12.2016 09:15, Jelle van der Waa wrote:
>> Putting things that need to stay together into one source package is
>> something different than providing various binary packages. I haven't
>> written that all plugins should be part of one single binary package.
> 
> How would you handle different releases and version numbers then?
> In theory it can be done with git and submodules in plugins.

different versions are of course not possible in this way. All
submodules are need to get the same version, even if there was no change
in a development cycle.

So for me it's to find a way between the maintenance of various
independent modules and needed work to get them stay in one repository.
I prefer the latter as much as possible as it decrease the overhead of
basic maintenance for each package like the build environment and
testing stuff.

The following packages I'd provide in one source tree and all in one
version:

kopano-webapp
 kopano-webapp-plugin-files*
 kopano-webapp-plugin-mdm
 kopano-webapp-plugin-smime
 (more "default" plugins ?)

This packages are more a standalone application and/or third-party modul:

kopano-webmeetings
spreedwebrtc
...

We need to find some consensus here as packaging a lot of small source
packages is on the long run a mess, please look at the current JS hell.
I won't have time to manage this for kopano-foo.. packages.

Rarely depended ...
Obviously kopanocore seems not landing in time for stretch. We would
need to have kopanocore in testing before 5th January, which means we
have kopanocore accepted (and buildable on all RC platforms) before 26th
December due the 10 day delay.

The kopano-webapp wasn't uploaded to NEW until now. So even if we got
kopanocore accepted I would propose to not ship kopanocore in stretch.
So we got more time to prepare the Kopano stuff for buster and backports.

-- 
Regards
Carsten Schoenert