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:
>>>>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
>>>>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.
It will be yet another ugly solution.
Feel free to do it, but *NO* in upstream sssd git repo.
>You will need to either use custom repositories (COPR, ppa ...) or
>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.
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.
Besides being a PITA, it doesn't make much sense, as distribution
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.
Some dependencies are optional and can be disabled for some distributions.
But new ding-libs will not be optional.
>These are exactly reasons why is very bad to maintain hardcoded
>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.
That's the problem you want to reinvent wheel. (spec file in this case)
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.
I don't want to see it. I already know it is uncomfortable and annoying.
However, Debian dependencies will remain there. We can, of course,
Debian packaging as well and pull it from there, but I'm not sure if that will
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.