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

Jakub Hrozek jhrozek at redhat.com
Tue Jun 24 07:03:58 UTC 2014


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

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

Sorry, I didn't bring this up. Yes, I would like to target RHEL6 with
master. Currently that's our oldest supported release.



More information about the sssd-devel mailing list