Subject: Re: [alpine-devel] Proposal: testsuite support in APKBUILDs

From: Ed Robinson <[email-masked]>
Date: Fri, 27 Jan 2017 08:10:19 +0000

I would prefer test over check and (testsuite). Test is a verb so fits
nicely with the other commands. "make test" is used about 4 times more
often than make check in the existing packages.
https://github.com/alpinelinux/aports/search?utf8=%E2%9C%93&q=make+test&type=Code
(634 results) vs
https://github.com/alpinelinux/aports/search?utf8=%E2%9C%93&q=make+check&type=Code
(180 results)

I think the idea is a good one overall and I think while naming is
moderately important, having the feature is more important than getting the
name right...

,Ed

On Fri, Jan 27, 2017 at 7:59 AM, 7heo <[email-masked]> wrote:

> I am really confused that you want to use a wrong vocab because GNU
> software already use it. Plus, it was my understanding that our tool's name
> isn't 'make' (since it's about identical terms).
>
> I understand that for many people this discussion may seems like a waste
> of time, but using the correct vocabulary is an essential part of
> code-as-documentation.
>
> Going with check is not a huge inaccuracy I admit; but it will most likely
> effectively hinder the understanding of newcomers while lowering the
> learning curve for GNU people/users.
>
> I can explain in a separate mail (or on IRC) why I think it is a bad
> enough idea to attract GNU contributors to alpine, to justify continuing
> this discussion; but I'll assume here that all alpine contributors share a
> similar view on the GNU code style.
>
> So, does anyone agree?
>
> Theo
>
> On Fri Jan 27 02:28:32 2017 GMT+0100, William Pitcock wrote:
> > Hello,
> >
> > In some ways I am inclined to agree with Jakub, mostly because "make
> > check" is the main way of invoking a testsuite on autotools platforms.
> > It is perhaps not the most correct description of the phase, but it
> > does fit with "make check" usage in autotools, so people would be
> > familiar with it.
> >
> > Lets move forward with check phase and !check in $features?
> >
> > William
> >
> > On Thu, Jan 26, 2017 at 8:34 AM, 7heo <[email-masked]> wrote:
> > > Hey,
> > >
> > > Since we're talking about vocabulary and semantics, I would rather
> avoid check, since it doesn't reflect what happens. A testsuite is a suite
> (set of, ordered, predictable) of tests (dynamic procedure to validate an
> element, that has to be executed). A check is merely an observation with
> assertion on an existing state. As an example, you can check the door is
> open, but you have to test if the lock works (you can't just check it in
> normal conditions and without a specialized apparatus).
> > >
> > > Long story short, I don't have any problem with making it shorter and
> simpler, but I would rather have something that matches what is actually
> does. :)
> > >
> > > Theo.
> > >
> > > On Thu Jan 26 14:08:29 2017 GMT+0100, Jakub Jirutka wrote:
> > >> Hi,
> > >>
> > >> currently we have the following phases: sanitycheck, builddeps,
> clean, fetch, unpack, prepare, mkusers, rootpkg, cleanup. All of them
> except rootpkg are verbs. So I’d prefer “check” (as Arch) instead of
> “testsuite”.
> > >>
> > >> Jakub
> > >>
> > >> > On 26. Jan 2017, at 10:26, Timo Teras <[email-masked]> wrote:
> > >> >
> > >> > On Wed, 25 Jan 2017 21:38:00 -0600
> > >> > William Pitcock <[email-masked]> wrote:
> > >> >
> > >> >> As such, I propose we add a testsuite() phase to the build process,
> > >> >> that runs after build(), but prior to package().  APKBUILDs should
> > >> >> override the testsuite phase, but the default_testsuite() function
> > >> >> will be a noop for the Alpine 3.6 release cycle that raises a
> warning
> > >> >> that the APKBUILD does not define any mechanism for running a
> > >> >> testsuite.  If "!testsuite" is defined in $features, the warning is
> > >> >> ignored.
> > >> >>
> > >> >> For cross-builds, the testsuite would be skipped unless the package
> > >> >> is noarch.
> > >> >>
> > >> >> After Alpine 3.6 (or maybe 3.7), we change the warning to a fatal
> > >> >> error, requiring APKBUILDs to explicitly opt out of running a
> > >> >> testsuite through $features.
> > >> >>
> > >> >> Thoughts?
> > >> >
> > >> > +1
> > >> >
> > >> > We have some packages that run 'make check' or similar, but it
> would be
> > >> > good to make it a separate step.
> > >> >
> > >> > The above plan sounds good to me.
> > >> >
> > >> > Thanks,
> > >> > Timo
> > >> >
> > >> >
> > >> > ---
> > >> > Unsubscribe:  [email-masked]
> > >> > Help:         [email-masked]
> > >> > ---
> > >> >
> > >>
> > >>
> > >>
> > >> ---
> > >> Unsubscribe:  [email-masked]
> > >> Help:         [email-masked]
> > >> ---
> > >>
> > >>
> >
>

---

From: Timo Teras <[email-masked]>
Date: Fri, 27 Jan 2017 10:15:02 +0200

On Fri, 27 Jan 2017 08:10:19 +0000
Ed Robinson <[email-masked]> wrote:

> moderately important, having the feature is more important than
> getting the name right...

'test' is a shell built-in and due to the way abuild is implemented, it
cannot be used. It would break lots of stuff.

I have no strong opinion over 'check' or 'testsuite'.

I'm planning to add 'rootbld' that will do a clean chroot build of the
package. So that would not be strictly a verb either. I have patch for
this, but it's pending a way to configure the repository URLs properly.

/Timo

---

---

From: 7heo <[email-masked]>
Date: Fri, 27 Jan 2017 08:55:30 +0000

What about 'tests' or 'runtests'?

But I agree with Ed that getting the feature is much more important than getting the name right.

Theo.

On Fri Jan 27 09:15:02 2017 GMT+0100, Timo Teras wrote:
>'���r��y�i�w�z����칻�&ޖ+-��i�w��{���zZZ���yׯz_�zZe��ljZb��b��h�

---

From: Leonardo Arena <[email-masked]>
Date: Fri, 27 Jan 2017 10:45:16 +0100

> What about 'tests' or 'runtests'?

Let's throw one more to the mix: "validate" ?

+1

-|_eo

---

From: scsijon <[email-masked]>
Date: Sat, 28 Jan 2017 00:22:36 +1100

the 'tests' switch (--tests) is what is used inside quite a number of 
packages for their internal building test steps so i wonder if that's 
appropriate and even then it may have different purposes. Maybe using it 
would get the builder/compiler confused if a problem ocurrs?

The real thing to think about before you give it a name is ?what do you 
actually want tested and how is it to proceed in yes|maybe|no 
situations. Is it a step in a package build, a step in checking for the 
overall release, or something else? Can someone outline what is to go 
where in the overall schema and what type of tests are likely to be 
actually needed please.

And Leonardo, validate is used internally in some packages for things 
like an internal crc of a code area or test against a corrupted or 
incorrect source file (usually minor code fixes at the third identity 
level being added but not altering the overall package name as it only 
uses two levels of version identity externally) so as much as I like it 
the best of what's been suggested so far I'm not sure it's appropriate 
or available, sorry.

---