[Kolab-devel] Proposal - Distro specific changes for Kolab 3

[Aeneas Jaißle]

Am Freitag, 24. Mai 2013, 11:08:48 schrieb Jeroen van Meeuwen:
> On 2013-05-22 15:36, Aeneas Jaißle wrote:
> > Hi everybody,
> > 
> 
> Hi Aeneas,
> 
> > I'd like to enhance Kolab's distribution support and make live for
> > (us) packagers easier.
> > 
> > For that, I put a layer between paths, service names, user and groups
> > (= between all that could differ on another distribution).
> > 
> > (...snip...)
> > 
> > Is something like this wanted upstream? Would this be the rights way
> > to do (in python)? Feedback welcome!
> > 
> 
> This is not a bad idea, but I hope you appreciate the following 
> considerations;
> 
> It is dangerously close to the list of settings that Kolab used to ship 
> as part of its kolab.conf.
> 
> We have found such lists to become problematic if (when) distributions 
> change their ways. "settings_fedora.py" would then need to become 
> "settings_for_fedora_before_version_16.py" and 
> "settings_for_fedora_after_and_with_version_17.py", if you will.
> 
> I would rather consider using "adaptive" code - surely we can test 
> whether a system uses systemctl, service or update-rc.d, and whether a 
> service name is httpd or apache2. While the current "implementation" [1] 
> is rather rudimentary, I would say a couple of if/else clauses could be 
> sufficient.
> 
> It is a good idea to pull such if/else clauses out of the respective 
> setup_*.py scripts, and perhaps make them some sort of utils.service() 
> function.
> 
> Furthermore, in packaging we have ./configure with options, and 
> pykolab/constants.py.in. It is probably better/easier to ./configure 
> --with-service-mechanism=systemctl than it is to maintain a list of 
> distributions and versions.
> 
> Kind regards,
> 
> Jeroen van Meeuwen
> 
> [1] 
> https://git.kolab.org/pykolab/tree/pykolab/setup/setup_roundcube.py#n196
> 
> 
Hi Jeroen,

so we'd pull the if/else clauses out and put them into a function. In this function we define (in detail) what services, service mechanism etc. to look for.
What about hard-coded paths? E.g. openSUSE is using /etc/apache2/conf.d/ instead of /etc/httpd/conf.d/, /var/lib/sieve/ instead of /var/lib/imap/sieve and so on. What would be the best place to define these?

- Aeneas