[Kolab-devel] Kolab 16 for Debian

Timotheus Pokorra timotheus at pokorra.de
Sat Nov 5 07:55:24 CET 2016


Hello Aaron,

> Until we had a few ... "events" ... that took up the team's time last month,
> we were actually planning on charting out and leading a packaging effort for
> 16.1 during October. I hope we will see this go forward this month. As soon as
> we have a firm "yes" on our availability, we'll let everyone know here.
That is a very helpful information. I think if there would be more
communication like this, it could motivate people to help with
packaging.

> One of the easiest things to do, if this is a challenge, is to create and ship
> a release version of Guam. This is that horrible, horrible thing (to
> packagers, anyways ;) known as "vendorization". If you run `make release` in
> the top level, you should get a fully self-contained set of binaries in the
> rel directory. And I mean fully self-contained. It will include the erlang
> runtime and everything.
>
> This gives you a zero-dependency,  no-nonsense package to ship.
>
> The downside is that it is "vendorized": if there is a useful update to Erlang
> or any of the (small number of) erlang libraries guam uses, it would need to
> be rebuilt. It also means the single guam package would be rather larger than
> if it was all split out into a bunch of packages as it is done in the Red Hat
> world.
>
> I have no personal opinion on which is better or worse. I know that packagers
> tend to hate the vendorized-builds that are more and more The Standard
> Practice for frameworks as varied as node.js, PHP and Erlang/Elixir. But it
> does make it easy to make shippable binaries you KNOW will work with ZERO
> conflict with any other applications.

Yes that is a big discussion in the distributions.
I think that with a vendorized build, the community is fully dependant
on the vendor. Although the community could help with packaging there
as well...
The vendor takes all the responsibility to deliver fully patched packages.

Jeroen sometimes hinted he wished that distributions would take on the
job of packaging Kolab.
Did I get that right?
I am thinking to invest time to get Kolab packaged in Fedora, and for
Epel7. But I would love to hear that that move would be welcomed.
For Debian, I had to pull out at some time, because I realized I had
to focus on one distribution.

With Mono, another open source project I am involved in, we did make
the jump from packages only provided by Xamarin, to get the latest
Mono 4.x into Debian, Ubuntu, Fedora, and now Epel/CentOS as well. It
was hard work, but has helped Mono to be available on more
distributions, and with more people that know how to build packages.
There is now a community of packagers, not only one man (Jo Shields)
at Xamarin who has to do all the packaging alone.

hope this makes sense,
  Timotheus


More information about the devel mailing list