Ludovic Courtès <l...@gnu.org> ezt írta (időpont: 2018. júl. 6., P, 23:05):
> Hello, > > Mark H Weaver <m...@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’. > >
