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

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Fri Jun 13 20:26:47 UTC 2014


On 06/13/2014 10:28 PM, Lukas Slebodnik wrote:
> 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.

Sorry, can you elaborate?

>> 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).

I understand that. All I'm saying is that the whole CI test suite depending
unnecessarily on complicated/fragile code (that being the .spec file and the
substitution), by means of requiring dependency installation through them at
the start, is not a good idea.

>> 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.

Duplication by itself is not an absolute evil. The effort required to sync
matters.

>> 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.

I agree that increased complexity of the duplicated code makes it worse.
However, as I stated before, a few conditions in addition to already present
distro family branching wouldn't hurt much. And I daresay a single condition
should be enough to tackle RHEL6 dependencies.

When we discussed this with Jakub, RHEL6 didn't come up, that's why I didn't
target it. I also didn't target the 1.11 branch yet, as it would need its own
set of fixes first. Do we target RHEL6 with master? If yes, I'll try targeting
RHEL6 and we'll see how the dependency tracking changes.

Nick



More information about the sssd-devel mailing list