Precedence: list
MIME-Version: 1.0
In-Reply-To: <i2ems4.oke5ti.1hge1d6-qmf@gmx.com>
References: <CA+T2pCEB9g=un1jx0x2k+wKNQWeBt8hijEwq1Yy+qLLvb0OVrw@mail.gmail.com>
 <20170126112655.44ad5c0e@vostro.util.wtbts.net> <4EDA0683-3991-44D0-882C-C34FBD4C38B2@jirutka.cz>
 <i2ems4.oke5ti.1hge1d6-qmf@gmx.com>
From: William Pitcock <nenolod@dereferenced.org>
Date: Thu, 26 Jan 2017 19:28:32 -0600
Message-ID: <CA+T2pCF+dFPhWBKcwdUSp_Fr1Jk=rT1Pweap6iPZMXjf6HFi8g@mail.gmail.com>
Subject: Re: [alpine-devel] Proposal: testsuite support in APKBUILDs
To: 7heo <7heo@mail.com>
Cc: jakub@jirutka.cz, alpine-devel@lists.alpinelinux.org, timo.teras@iki.fi
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 <7heo@mail.com> 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 o=
f, 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 y=
ou have to test if the lock works (you can't just check it in normal condit=
ions and without a specialized apparatus).
>
> Long story short, I don't have any problem with making it shorter and sim=
pler, 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, f=
etch, unpack, prepare, mkusers, rootpkg, cleanup. All of them except rootpk=
g are verbs. So I=E2=80=99d prefer =E2=80=9Ccheck=E2=80=9D (as Arch) instea=
d of =E2=80=9Ctestsuite=E2=80=9D.
>>
>> Jakub
>>
>> > On 26. Jan 2017, at 10:26, Timo Teras <timo.teras@iki.fi> wrote:
>> >
>> > On Wed, 25 Jan 2017 21:38:00 -0600
>> > William Pitcock <nenolod@dereferenced.org> 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 b=
e
>> > good to make it a separate step.
>> >
>> > The above plan sounds good to me.
>> >
>> > Thanks,
>> > Timo
>> >
>> >
>> > ---
>> > Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
>> > Help:         alpine-devel+help@lists.alpinelinux.org
>> > ---
>> >
>>
>>
>>
>> ---
>> Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
>> Help:         alpine-devel+help@lists.alpinelinux.org
>> ---
>>
>>


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---