On 21.11.2016 10:32, Christian Heimes wrote:
On 2016-11-21 10:26, Jan Cholasta wrote:
On 11.11.2016 18:28, Christian Heimes wrote:
On 2016-11-11 17:46, Martin Basti wrote:

On 11.11.2016 15:25, Christian Heimes wrote:

I have released the first version of a new design document. It
how I'm going to improve integration of FreeIPA's client libraries
(ipalib, ipapython, ipaclient, ipaplatform) for third party developers.



Hello, I have a few questions:

1) dynamic platform files

Currently all RHEL/fedora-derived platforms work with the same
rhel/fedora packages. How do you want to achieve this with dynamic
platform files, do you want to keep mappings between platforms and
platform file? What about distributions that have in /etc/release
just mess?

I don't use /etc/releases but /etc/os-release. There is no mapping
involved. If a distribution has no /etc/os-release or a messed up
/etc/os-release, then it needs to be fixed by the distribution. It's a
common standard and all relevant distributions support this standard.

RHEL has ID=rhel and no ID_LIKE -> ipaplatform.rhel

Fedora has ID=fedora and no ID_LIKE -> ipaplatform.fedora

CentOS has ID=centos and ID_LIKE="rhel fedora"
-> ipaplatform.rhel

Even my Raspberry has an /etc/os-release with ID=raspbian and
ID_LIKE=debian -> error, soon ipaplatform.debian

There is more to ipaplatform than /etc/os-release offers. How do you
differentiate between e.g. "Debian with SysV init" and "Debian with


do you support FreeIPA on Debian variants with SysV init?

This is not an issue of what is supported now, but rather what is supportable in the future. Even if Debian with SysV init is not supported ATM, someone might want to add support for it in the future, and the design should not prevent them from doing so.

Jan Cholasta

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to