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

Lukas Slebodnik lslebodn at redhat.com
Wed Jun 25 18:51:24 UTC 2014


On (25/06/14 19:16), Nikolai Kondrashov wrote:
>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.
>
We must maintain dependencies in spec anyway and syntax in spec is simpler.

>>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?
>
It can be.
You can maintain own repositories with new dependencies.

>>>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
But it does not mean it is right way.

>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?
In 99%, "reinventing wheel" != improvement.
http://xkcd.com/927/

>
>>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.
>
1. extract dependencies from spec file
2. install extracted dependencies
3. installation will fail due to missing new pacakges.
   --> result: test failed and you don't need to even run configure.

Solution:
    a) disable CI test for this plafortm
    b) add additional repositories for problematic platform (COPR, ppa ...)

LS



More information about the sssd-devel mailing list