Hello Simon,
I'll add the bug report to the recipients so other can are also see this
mailing.
As you see I'm answering time shifted, it's the time of the year were
more things pop up that needs to be done as usual.
Am 07.12.20 um 12:29 schrieb Simon Eisenmann:
> Hey Carsten,
>
> thanks for including me in this. I understand why you want to orphan
> kopanocore completely and also agree that it would be the for the
> best. We will also have an internal discussion about this.>
> Generally we improved our release situation a bit with the announce
> of Kopano One and everything related to it but from a Debian point of
> view, the releases are still too frequent and hard too follow.
Frequent releases aren't a real problem. I appreciate them, they show
mostly an active and healthy upstream project.
For Kopano the underlying team in Debian is currently based on only two
persons, Guido and myself, no new contributors came up. In the past Mark
has done a great job to simplify the workload on our side by providing
information, useful tips, intermediary and some kind of glue from Debian
to upstream.
I personally don't use Kopano as it's functionality is to much for me, I
don't need most of the features. I've done all the work just for fun and
because Kopano is the first big alternative for M$ Exchange.
> Our stack has always been complex and i am wondering if it were worth
> the effort for the users to actually have a 100% feature complete
> Kopano in Debian at some point under the assumption (like you stated)
> that our stack is using broadening its use of technologies (Go, Node,
> Rust ..).
Complexity isn't really matter (and shouldn't) in my eyes. We have other
complex packages in the archive which are the wide ground the
distribution is build up. It took up years but today you can run e.g a
GitLab instance only with packages from Debian.
And I don't see a real reason why Kopano could not be part of Debian,
currently the only preventing thing is the man power to drive all the
things. Even if you (Kopano) is using their own repository to provide
packages for their costumers I see a big gain in the maintenance of
required packages of Kopano direct dependencies if Kopano would like to
improve the situation on this.
Kopano isn't the only company that is maintaining some additional
packages on their own to provide the full usability of their own
packages. But in some cases these additional packages are breaking the
update process of the underlying system, or at least bring in some side
effects. This ends that users need to run and administrate machines that
are exclusive for third party software. I see such systems on my day job
and such machines are cost a lot of time and are always some kind of
special.
I also see that Kopano is building their own packages based on more than
the usual C/C++ stuff, so it's not that this work isn't already done.
It's just a small step to do this work upstream (means manage these
packages in Debian) and get the added value quite automatically in all
supported releases and also into Ubuntu. We happily sponsor package
uploads, we've done this for z-push now for over 3 years. Thanks to Roel
who prepared mostly all uploads.
> A fully functional Kopano system would include:
>
> - Kopano Server and related software (kopanocore, libkcoidc, gsoap +
> patches, libical + patches, libvmime + patches)
You mentioned here three packages with additional patching, so far I
understand. :)
And gsoap isn't a corner package. That's exactly the situation I mean.
The gsoap maintainer is very responsive and open minded for issues like
that, this was my impression I've made in the past were we had a similar
situation.
libvmime is different, we don't have seen a release (again) for two years.
> - Kopano Web server (kweb)
> - Kopano Web apps (webapp, newer progressive web apps)
> - KDav
> - Z-Push
>
> How do you see this from the Debian perspective - is it even feasible
> or wanted to have a stack like this including all its build
> dependencies (which are probably like 2000 individual things if you
> cound Javascript modules) - what is the Debian position on this?
I think the situation for Debian is relatively simple and driven by the
DFSG. As long software is complaint to these rules there are no reason
why we don't include this software.
The above list isn't much differing from the current package situation.
I only see directly a new library libkcoidc as a new dependency which
need to get packaged.
But yes, quite a lot of time can be spend on unravel PHP and JS
dependencies to not ship big blobs of required additional packages.
> At Kopano we solve this problem by having a build pipeline which has
> a pre-build step which fetches all the dependencies using the
> corresponding system (Go, Node, Rust) and as a second step package it
> which makes it rather easy.
Debian knows that projects tend to do this, but as you also know for
sure the view on this by Debian is that this model isn't
