From: "Gábor Boskovits" <boskovits@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: Guix-devel <guix-devel@gnu.org>
Subject: Re: shortening the git test suite
Date: Sat, 7 Jul 2018 10:07:41 +0200 [thread overview]
Message-ID: <CAE4v=phRx4Sw-=oB=6-M2xxzcTLrUZAd22O6DBtV1cAX-FaghQ@mail.gmail.com> (raw)
In-Reply-To: <87va9s9itb.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2893 bytes --]
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’.
>
>
[-- Attachment #2: Type: text/html, Size: 3565 bytes --]
next prev parent reply other threads:[~2018-07-07 8:07 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-30 19:34 shortening the git test suite Ricardo Wurmus
2018-06-30 23:52 ` Gábor Boskovits
2018-07-01 13:54 ` Marius Bakke
2018-07-05 9:28 ` Ricardo Wurmus
2018-07-02 4:56 ` Mark H Weaver
2018-07-02 8:39 ` Gábor Boskovits
2018-07-05 9:28 ` Ricardo Wurmus
2018-07-05 8:44 ` Chris Marusich
2018-07-05 9:21 ` Ricardo Wurmus
2018-07-06 9:46 ` Gábor Boskovits
2018-07-06 18:19 ` Mark H Weaver
2018-07-06 21:05 ` Ludovic Courtès
2018-07-07 8:07 ` Gábor Boskovits [this message]
2018-07-07 16:44 ` Mark H Weaver
2018-07-07 21:37 ` Ricardo Wurmus
2018-07-08 22:41 ` Mark H Weaver
2018-07-09 7:47 ` Ricardo Wurmus
2018-07-11 12:46 ` Ludovic Courtès
2018-07-12 9:27 ` Chris Marusich
2018-07-08 1:29 ` Mike Gerwitz
2018-07-06 21:09 ` Automatic branch merging upon build completion Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE4v=phRx4Sw-=oB=6-M2xxzcTLrUZAd22O6DBtV1cAX-FaghQ@mail.gmail.com' \
--to=boskovits@gmail.com \
--cc=guix-devel@gnu.org \
--cc=ludo@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).