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

Lukas Slebodnik lslebodn at redhat.com
Wed Jun 25 11:59:50 UTC 2014


On (25/06/14 14:38), Nikolai Kondrashov wrote:
>On 06/25/2014 02:29 PM, Sumit Bose wrote:
>>On Wed, Jun 25, 2014 at 01:02:04PM +0200, Jakub Hrozek wrote:
>>>On Wed, Jun 25, 2014 at 12:55:15PM +0200, Lukas Slebodnik wrote:
>>>>Sorry, it looks terible.
>>>>If you want to maintain dependencies yourself in CI script. Feel free to do in
>>>>extra git repository "sssd CI" on github.
>>>
>>>We already have stuff in contrib/ that is not part of core SSSD and
>>>might even not work as far as we know (gentoo initscript..)
>>>
>>>>If you want to have script in upstream sssd repo you will need to ger rid of
>>>>this duplication.
>>>
>>>Except you still have to maintain the Debian deps.
>>>
>>>While I don't share the fear Nick has over code in RPM scriptlets, I
>>>don't see the deplist as a blocker.
>>
>>Would it be possible to build the packages (would require something like
>>a deb: target in Makefile.am) and then let yum/apt figure out the
>>dependencies and install them?
>
>It is possible.
>
>However, aside from the increased maintenance burden, that would essentially
>require having packaging for any other distribution we would like to test with
>as well, or forgoing that approach there, mostly negating the benefit.
>
There is very big change that new dependencies (or new version of packages)
will be only in fedora rawhide and will not be packaged in any other
distributions. How will you solve it? You will need to either use custom
repositories (COPR, ppa ...) or install dependencies from source.

Do you want to maintain packages for debian yourself? How will you solve it
with hardcoded dependencies in CI script? Will you extend if else conditions
for fedora 20 and fedora rawhide? How do you plan to solve problem on debian?

These are exactly reasons why is very bad to maintain hardcoded build
dependencies in upstream CI script and current version of CI script
in upstream at all.

If you want to argue that it is a hypothetical situation. It isn't.
The best example is the newest version of ding-libs and yelles's patches for
GPO. It will be pushed into upstream in near future.

>This would also make running even the most basic CI tests, like autoreconf,
>configure, coding style verification (not done yet), etc., depend on the
>correctness of the packaging code.
>

It is real blocker from my POV.

LS



More information about the sssd-devel mailing list