[Kolab-devel] Fedora packaging

[Paul Boddie]

On Thursday 23. January 2014 18.33.59 Karel Volný wrote:
> 
> > Although concrete decisions related to policy may differ somewhat, there
> > might be some benefit at looking at plans for Debian and perhaps
> > openSUSE, too.
> 
> you mean distro plans or Kolab plans? - any link what to read, please?

Distro plans, really. There's the pkg-kolab mailing list for Debian, although 
I think only Paul Klos has been posting there lately:

https://lists.alioth.debian.org/pipermail/pkg-kolab-devel/

The openSUSE plans or techniques have mostly been mentioned on this list in 
relation to the way the configuration is done for that distribution.

> > I haven't really looked at the Debian packaging much since December, but
> > I did write up an approach that kept setup-kolab and made it work
> > slightly better with the way packages are installed and configured in
> > Debian, and it is conceivable that Fedora behaves similarly enough that
> > the general dependency structure and approach is at the very least worth
> > looking at:
> > 
> > http://blogs.fsfe.org/pboddie/?p=623
> 
> "Take MySQL as an example. Upon installing the appropriate Debian package
> providing the MySQL server, the user is prompted to set up the
> administrative credentials for the server. After this brief interaction,
> MySQL should be available for general use without further configuration
> work, although it may be the case that some tuning might be beneficial. It
> seems to me that Kolab could be delivered with the same convenience in
> Debian."
> 
> Exactly my point! (in principle)
> 
> BTW, thanks for the diagram, great introduction for me.

Note that the diagram shows the dependencies as I have changed them to be, not 
how they currently are in the OBS packages, so kolab-conf is actually deeper 
in the dependency tree after my modifications so that other packages can use 
setup-kolab.

I think I could probably put together a nice diagram of the current 
dependencies, as well as some architecture or dataflow diagrams, since the 
dependencies probably don't represent the architecture accurately, anyway.

[setup-kolab]

> In an ideal world, it would be just a matter of changing a few globals,
> like where the distros like to put the stuff, how do they call things,
> what initsystem they use etc. and running the same script everywhere. In
> reality ... I can hardly imagine it would work that way, but we can at
> least try to split the steps into generic and distro-specific.

I'd hope that even if distros start to diverge on their init systems, they 
would at least provide common tools to configure them.

> > The other sticking point appeared to be delivering Kolab to work with the
> > official distribution packages for things like cyrus-imapd and roundcube
> > (on Debian, at least) where there may need to be some improvements from
> > unofficial packages ported over to the official ones.
> 
> Yes, that's the thing I'd like to see resolved too. While Red Hat has taken
> the opposite direction with Software Collections, I highly doubt that
> average users would be much happy having multiple instances of basically
> the same code, having to wonder which one is getting the fixes they care
> about, different places to track bugs, and how do the alternative packages
> fit in the rest of the system ...

Right. People don't really want to have to override their repository settings 
to get some alternative packages. Having distro-upstream support also makes a 
strong statement about the maturity and viability of software.

Paul