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

Nikolai Kondrashov Nikolai.Kondrashov at redhat.com
Wed Jun 25 16:16:36 UTC 2014


On 06/25/2014 06:26 PM, Lukas Slebodnik wrote:
> On (25/06/14 17:21), Nikolai Kondrashov wrote:
>> 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:
>>> 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.
>>
> It will be yet another ugly solution.

Not a bit uglier than what we'll have to do in the .spec file.

> After pushing yelley's GPO patchets, it will mean that CI tests will not pass
> until new version of ding-libs will be in debian.
> In another way, we will ignore/disable debian for few weeks/months.

Well, that can't be helped, can it?

>> 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.
>>
> That's the problem you want to reinvent wheel. (spec file in this case)

I don't exactly reinvent the wheel here, rather reimplement a small part of
it. Still, people "reinvent wheels" all the time. It's not a problem in itself
and should be viewed in context. E.g. how much of the wheel is being
reinvented and what are the actual benefits and drawbacks. Besides, how do you
improve without reinventing?

> On (25/06/14 16:51), Nikolai Kondrashov wrote:
>> On 06/25/2014 05:33 PM, Simo Sorce wrote:
>>> I personally do not care too much where you keep the dependencies,
>>> although having them only in one place (spec file) will make it much
>>> easier to manage.
>>
>> Let's see how it goes. If it becomes uncomfortable or annoying, then I'll
>> implement pulling them from the spec file, some way or another.
>>
> NO.
> I don't want to see it. I already know it is uncomfortable and annoying.

I guess this can't be helped.

Unless anyone else is against that, I'll implement extracting dependencies
from contrib/sssd.spec.in after I return from my vacation on July 14th.

>> However, Debian dependencies will remain there. We can, of course, implement
>> Debian packaging as well and pull it from there, but I'm not sure if that will
>> be worthwhile.
>>
>
> Soon, there will be problem with debian anyway. (ding-libs 4.0)
> IMO, it is a minority platform (the same with others future platforms in CI)
> If sssd could not be build due to old dependencies we will need to
> either ignore it or maintain dependencies ourself.

Sure, but I fail to see how the .spec file use will help with that.

Nick



More information about the sssd-devel mailing list