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

Jakub Hrozek jhrozek at redhat.com
Wed Aug 6 17:37:09 UTC 2014


On Tue, Aug 05, 2014 at 05:59:39PM +0300, Nikolai Kondrashov wrote:
> 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?

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.

> 
> 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
> _______________________________________________
> sssd-devel mailing list
> sssd-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-devel



More information about the sssd-devel mailing list