[SSSD] [RFC] Add basic support for CI test execution

Lukas Slebodnik lslebodn at redhat.com
Fri Jun 13 19:28:10 UTC 2014


On (13/06/14 20:27), Nikolai Kondrashov wrote:
>On 06/13/2014 06:52 PM, Lukas Slebodnik wrote:
>>On (13/06/14 16:50), Lukas Slebodnik wrote:
>>>On (13/06/14 16:49), Nikolai Kondrashov wrote:
>>>>On 06/13/2014 03:14 PM, Lukas Slebodnik wrote:
>>>>>On (13/06/14 14:50), Nikolai Kondrashov wrote:
>>>>>>On 06/13/2014 02:00 PM, Lukas Slebodnik wrote:
>>>>>>>On (13/06/14 13:40), Nikolai Kondrashov wrote:
>>>>>>However, the fact that someone (who has different situation) does something,
>>>>>>doesn't mean that it's an efficient thing to do. Could you please provide the
>>>>>>rationale for your solution, so we can compare benefits and drawbacks and make
>>>>>>a rational decision? Perhaps I'm biased, or am missing something.
>>>>>>
>>>>>I wrote it few times. I do not want to maintain two different list of build
>>>>>dependencies. The referential and only source should be spec files in contrib
>>>>>directory. I already proposed few solutionswhich will solve  problem for you
>>>>>     * yum-builddep
>>>>>     * obtaining dependencies from src.rpm with rpm.
>>>>
>>>>I'm sorry, but "I do not want" doesn't count as a rationale, especially since
>>>>there are other people maintaining the package as well. What are the benefits
>>>>of your solution for everyone? What do we win with it?
>>>>
>>>>Also, as I stated before, extracting dependencies from the RPM is not the main
>>>>problem. The main problem is unnecessary complexity.
>>>I'm sorry but you should explain to me benefit of maintaining the same build
>>>dependencies on two different places.
>>>
>>>In near future, there will be bigger differences between rhel6, rhehl7 and
>>>fedora. You will need to maintain very similar dependencies in CI for rhel6
>>>and fedora22(alias new rawhide). We already maintain them in sssd.spec.
>>>
>>common dependencies for rhel6 and fedora20
>>   augeas-devel autoconf automake bind-utils c-ares-devel check-devel dbus-devel
>>   dbus-libs docbook-style-xsl doxygen findutils gettext-devel glib2-devel
>>   keyutils-libs-devel krb5-devel libcollection-devel libdhash-devel
>>   libini_config-devel libldb-devel libselinux-devel libsemanage-devel
>>   libsmbclient-devel libtalloc-devel libtdb-devel libtevent-devel libtool
>>   libxml2 libxslt m4 nspr-devel nss-devel openldap-devel pam-devel pcre-devel
>>   pkgconfig popt-devel python-devel samba4-devel selinux-policy-targeted
>>
>>el6 specific:
>>   libnl-devel
>>
>>fc20 specific:
>>   libcmocka-devel cifs-utils-devel systemd-devel libnl3-devel
>
>Here is the number of commits involving BuildRequires per year:
>
>$ git log --format='%h %cd' -G 'BuildRequires' contrib/sssd.spec.in |
>    cut -d' ' -f6 | sort | uniq -c
>
>      3 2009
>     12 2010
>      7 2011
>      4 2012
>      4 2013
>      3 2014
>
>Not all of them actually add or remove dependencies, some just move them
>around.
>
You can change something in spec file which will for on fedora 20, but it will
break build on rhel6. This is not a valid argument.

>My point is, it is not worth it to make CI duplicate autoconf substitution
this substituion is very simple.

>code to generate valid .spec file, making all of the CI tests depend on it,
>to make it necessary to debug a (complicated) .spec file and the substitution
It is not about debugging spec file. The purpose should be to test spec
file from sssd master on latest version of fedora and the latest
unofficially supported version of rhel. (nowadays rhel6).

>code to run *any* CI tests in case it breaks. I think it is not worth it to
>split package list source into two for just one distribution family, making
>the code more confusing. IMO, it is not worth it to force users to enter extra
>passwords, because yum-builddep cannot be trusted a sudo rule, or build srpm
>and then rely on a kludge of feeding its dependencies to yum, increasing
>fragility further.
If you do not want to use yum-builddep you can use different method
for extraction build dependencies from spec file. It will will save one typing
of password.

>I think the above is not worth avoiding adding or removing one or two package
>names in one extra place just a couple of times a year.
>
It is still a duplication.

>I find it unlikely that we will suddenly need to change our list of build
>dependencies or conditionals often (say, 20-30 times a year). However, if it
>happens or if it is predicted to happen, I'll implement the dependency list
>extraction as soon as possible, because then it will be worth it.
>
I realised that you appended systemd-devel into DEPS_LIST for DISTRO_BRANCH
"-redhat-*". With current version of CI script it will be impossible to test on
rhel6. It is a big drawback. My assumption is to use CI at least for rhel6,
current fedora and some version of debian/ubuntu. Your current version cannot
fulfil this requirement. It is my fault that I didn't clarify it in
beginning of discussion.

You will need to maintain different set of build dependencies for rhel6 and
fedora 20 (or rhel7). It worth to implement dependency extraction
from spec file now.

LS



More information about the sssd-devel mailing list