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

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Fri Jun 13 17:27:49 UTC 2014


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.

My point is, it is not worth it to make CI duplicate autoconf substitution
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
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.

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.

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.

Nick



More information about the sssd-devel mailing list