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

Simo Sorce simo at redhat.com
Wed Jun 25 14:33:45 UTC 2014


On Wed, 2014-06-25 at 17:21 +0300, 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 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.

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.

However if you are going to replicate dependency management then you
have to deal with version numbers of dependent packages as well.
I see you list a ton of packages in your scripts but w/o version
numbers. That will not work. And having to wade through CI results to
find out the problem lies in an older library being used is a waste of
time we should not put on ourselves.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York




More information about the sssd-devel mailing list