Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2018. júl. 6., P, 23:05):

> Hello,
>
> Mark H Weaver <mhw@netris.org> skribis:
>
> > Why do you say that only upstream needs to worry about it?  I would
> > think that you could say the same thing about almost any test suite, but
> > there's always the possibility that our particular combination of input
> > versions, or the unusual aspects of Guix, might break something that
> > upstream doesn't know about.
> >
> > I would think that git-svn interop is something that any user of the
> > git/svn integration needs to worry about.
>
> I agree.
>
> > If we feel that very few of our users care about git-svn interop,
> > another option would be to add a lighter variant of 'git' that does not
> > include SVN support.  It would probably be a good idea to have a
> > 'git-minimal' package anyway, for use by our 'git-fetch' origin method.
> > Naturally, only the 'git' package variant that includes SVN support
> > would need to run the SVN tests.
>
> Yeah, I think we could to do something like this in this case.
>
> Instead of ‘git-minimal’, we  could have ‘git’ without SVN support, and
> have a separate ‘git-svn’ package.  We can probably arrange for that
> ‘git-svn’ package to only provide the relevant libexec/git-core bits
> (git-svn is just a Perl script anyway.)
>
> Thoughts?
>
> > Also, looking ahead, I think it would be great if we could eventually
> > move to a model where the tests of some packages are split off into
> > separate derivations.  Similarly, we could work toward splitting off
> > documentation generation to separate derivation for selected packages.
> > The most important advantage to this approach is that it would allow
> > inputs needed only for tests or docs to be omitted from the inputs of
> > the main package.  I expect that this will in many cases be needed to
> > prevent circular dependencies, and it could also greatly reduce the
> > amount of rebuilding needed after updating certain packages.
>
> Currently if test fails, the whole derivation fails, and you can’t
> install your package.  If tests were run separately, this would no
> longer hold: you could get your package regardless of whether tests
> fail.  How would you address this?  I guess that calls for a new build
> model, no?
>
>
One example where this can be seen in action is the dependency of
java-jarjar on java-asm-bootstrap. java-asm-bootstrap is java-asm without
the tests, it is exactly
there to break a dependency cycle. java-asm is a full rebuild using tests.
java-asm-bootstrap is defined, while java-asm is define-public-ed (here a
full rebuild is involved). I'm not sure that a full rebuild can be worked
around in all cases, I guess that sometimes test capabilities are detected
at configure time. WDYT?

Thanks,
> Ludo’.
>
>