[SSSD] [PATCHES] Make sssd.spec.in work without libini_config >= 1.1.0

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Tue Aug 5 14:59:39 UTC 2014


On 08/05/2014 04:31 PM, Lukas Slebodnik wrote:
> On (31/07/14 12:04), Nikolai Kondrashov wrote:
>>From 7176ca7bcefd99b330b9be5c5b7bc294462065b8 Mon Sep 17 00:00:00 2001
>> From: Nikolai Kondrashov <Nikolai.Kondrashov at redhat.com>
>> Date: Wed, 30 Jul 2014 21:37:10 +0300
>> Subject: [PATCH 3/3] build: Cater to distros with older libini_config
>>
>> Cater to distributions with libini_config-devel < 1.1.0 in sssd.spec.in:
>> don't require newer libini_config-devel, build with --without-samba,
>> and don't build "ipa" and "ad" provider packages.
>> ---
>
> The purpose of ticket #1974 was to simplify upstream spec file, which is used
> for building rpms for fedora and rhel/centos. The last patch is against this
> idea.

I wouldn't say so exactly. We can still remove RHEL5 and Fedora 17 conditions
from the spec file and at the same time have conditional requirement of
libini_config-devel >= 1.1. However, as to whether this would be the best
solution or not see below. I understand that you wouldn't like to see any
unnecessary complexity in the spec file.

> The package libini_config-devel is part of ding-libs, which is developed by
> SSSD developers (we have full control). This is a reason why there is not
> conditional build in spec file and we decided to have strict requirement for
> libini_config-devel >= 1.1

Understood.

> The main purpose of CI should be to test new features, primary on fedora and
> rhel/centos. In last version of SSSD, we enhanced integration with AD and this
> last patch will disable this provider on el6 and el7. It is step back.
>
> I test sssd from master branch with modified version of epel-6-x86_64.cfg and
> epel-7-x86_64.cfg. They contain extra repositories with ding-libs-0.4.

This patch was the result of an IRC discussion I had with Jakub, where we
basically concluded that maintaining packages for *all* the dependencies
currently and potentially necessary to enable all the (newest) features on at
least some currently released distros (my idea originally) would be too much
of a burden (especially considering Samba and Kerberos), and we can limit
testing new features to the baseline of Fedora Rawhide (for which purpose I
brought up a new Jenkins node).

However, if we limit these only to (some) packages we "control" and know how
to build properly for corresponding distros, then perhaps it will be
manageable. Lukas, am I right that you already maintain a set of repos for
ding-libs? We can still disable features which require other packages.

Still, if we are to use that in CI, we'll have to fully commit to the
maintenance of a repository holding these packages and will have to make it
official: mention it in the developer instructions along with supported
distros.

Then, if we would like to use this repo to enable new features not only for
mock builds, but for the native CI builds as well (benefiting test coverage,
valgrind, clang scanner, etc. on older distros), we'll have to add
instructions to add this repo to yum configuration, so CI could install the
newer packages.

It would also be nice to have a similar repo for Debian testing.

(BTW, regardles of the above, we might need to add something like a --no-deps
option to the CI script for those wishing to install/use dependencies in other
ways, say from source)

So, would having the newer features depending only on (some) packages
"controlled" by us be tested on some currently released distros worth the
extra effort partially described above? How many of features being added
depend only on "our" packages, usually?

Jakub, what do you think?

If we agree this might be feasible, I'll implement using such a repo in CI.

And perhaps if this works, later we'll even be able to put some of the
packages we don't "control", but which are easier to build there, on
occasions.

Nick



More information about the sssd-devel mailing list