On 06/25/2014 02:02 PM, 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..)
Having CI in a separate repo will bring much synchronization pain with it,
making it much less useful.
> 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.
I don't really fear the RPM scriptlets (they're not even a problem), I'm just
a bit uncomfortable about macros. Anyway, that was a minor point against
extracting dependencies from the spec file, which got discussed way too much
out of principle. Let's forget about it for now.
The major point is having the whole of CI (as having dependencies installed is
the first and required step) depend on complicated piece of code that is the
spec file and duplicated configure's substitution logic required to make it
valid. If those break, none of the CI tests will run. And all we gain with it
is avoiding putting a package name for one distribution family in one more
place several times a year.
OTOH, without it, the spec file will still be verified with mock builds, while
the other tests will still be able to run, even if the spec file is broken.
Well, not at the present, as the suite will abort on the first error, but
with the use of Epoxy test framework (coming later) they will.
Nick