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

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Wed Jun 25 14:21:57 UTC 2014


On 06/25/2014 02:59 PM, Lukas Slebodnik wrote:
> 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?

I will add them to the dependency list under a Fedora condition.

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

I don't plan to maintain packages for distributions that don't have them.
Besides being a PITA, it doesn't make much sense, as distribution package
maintainers will only use packages that are already there. If they add some
packages for use with sssd, then we'll be able to use them as well.

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

The current CI dependency management does what any packaging system does for
that purpose. Only it is simpler and doesn't have parts it doesn't need.

The only problem with it is that it duplicates the package list of the RPM
packaging, which, as I argued before, is a tradeoff.

Sincerely,
Nick



More information about the sssd-devel mailing list