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