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

Lukas Slebodnik lslebodn at redhat.com
Thu Aug 7 07:31:30 UTC 2014


On (06/08/14 21:00), Nikolai Kondrashov wrote:
>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.
totally agree.

>>
>>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.
>
I have already created ding-libs repo
    https://copr.fedoraproject.org/coprs/lslebodn/ding-libs/
It is available for all necessary platforms: epel-{5,6,7} and fedora-{19,20}
fedora >= 21 has already new version of ding-libs.

LS



More information about the sssd-devel mailing list