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

Lukas Slebodnik lslebodn at redhat.com
Tue Jun 24 07:43:15 UTC 2014


On (24/06/14 09:03), Jakub Hrozek wrote:
>On Fri, Jun 13, 2014 at 11:26:47PM +0300, Nikolai Kondrashov wrote:
>> 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.
>
>+1
>
>If the CI would yell at me when there is a difference between spec file
>and the list (which we need to maintain for Debian anyway), I'm fine
>
The right approach will be to have upstream version of debian-specific files.
We can try to generate file with spec2deb (not tested)
or maintain upstream version of
http://anonscm.debian.org/gitweb/?p=pkg-sssd/sssd.git;a=blob;f=debian/control;h=a209b930a0a5083c21f69aca224d4c45c9130fa0;hb=HEAD

We have a member in team with debian packaging experiences :-)

LS



More information about the sssd-devel mailing list