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

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Wed Aug 6 18:00:06 UTC 2014


On 08/06/2014 08:37 PM, Jakub Hrozek wrote:
> On Tue, Aug 05, 2014 at 05:59:39PM +0300, Nikolai Kondrashov wrote:
>> On 08/05/2014 04:31 PM, Lukas Slebodnik wrote:
>>> 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?
>
> I'm fine with creating a repo with *ding-libs*, because it's a small
> package, developed by us and understood by us. So in this particular case
> of ding-libs, I'm fine with us putting the package into the buildroot or
> some special repo. But ding-libs is a special case.
>
> What I don't like is us maintaining a repo with large packages like
> Samba or Krb5 if/when we depend on new features in these packages. That
> would be too much of a burden. If we rely on a feature that depends on
> the latest Kerberos or Samba, my opinion is that we should make it easy
> to disable the functionality and run CI only for the supported subset of all
> features and run the full subset on rawhide or F-<latest> maybe.
>
> This is no different from a user grabbing a tarball of latest SSSD and
> compiling it on Debian or Centos 6 maybe. They're not going to get all
> the features either, fine by me. The important thing for me is that
>      a) existing functionality doesn't regress on any platform
>      b) all functionality is tested on at least one platform
>
> I really don't think we have the time to maintain all the missing deps
> for all the packages we depend on and all the platforms we test.

Thanks, Jakub.

Lukas, would you be willing to maintain such a repository and to make it
official, accepting public reliance on it?

I'd say that it might be better to give it a more abstract name, not including
"ding-libs", or a person's user name, giving us more flexibility in the
future.

Nick



More information about the sssd-devel mailing list