On 2016-11-21 10:46, Jan Cholasta wrote:
> 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:
>>>>>> Hello,
>>>>>> I have released the first version of a new design document. It
>>>>>> describes
>>>>>> how I'm going to improve integration of FreeIPA's client libraries
>>>>>> (ipalib, ipapython, ipaclient, ipaplatform) for third party
>>>>>> developers.
>>>>>> http://www.freeipa.org/page/V4/Integration_Improvements
>>>>>> Regards,
>>>>>> Christian
>>>>> 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
>>> systemd"?
>> Timo,
>> 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.

My proposal does not prevent sysv init support. In fact it makes it even
easier to support it. In case Debian SysV Init does not have a distinct
ID in /etc/os-release, I can easily add some additional check like

if platform == 'debian' and os.path.realpath('/sbin/init') !=
    platform = 'debian_sysvinit'


Attachment: signature.asc
Description: OpenPGP digital signature

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

Reply via email to