[aur-general] Long check() function in AUR packages

William Giokas 1007380 at gmail.com
Fri Nov 22 16:33:35 EST 2013


On Fri, Nov 22, 2013 at 01:00:32PM -0800, Anatol Pomozov wrote:
> Hi,
> 
> I am a big proponent of using automation testing. Tests saved me many
> times at my $dayjob projects. That is why I strongly believe that
> every arch package should have check() function - it is better find a
> problem at build time, rather than get a crash while running the
> application.
> 
> But some projects have quite large test suites. v8,rethinkdb,tup-git
> are examples - their tests take 10 minutes or even more. Some AUR
> users complain that it is too long. Even worse - there can be flaky
> tests that work fine for me but fail for some users.
> 
> What is the best practices in this situation? I see a few possible answers:
> 1) Tell users relax and enjoy running tests. Tests are for their own good.
> 2) Tell users to disable (!check) option in /etc/makepkg.conf
> 3) Maybe AUR install scripts (like yaourt) should not run tests at
> installation time? Or at least make it configurable?
> 
> What do you think is the best option?

This is a user issue. If their setup doesn't pass the tests, then there
is a very good chance that it won't work. If they're too lazy to run the
tests, they can skip them either in the config or with a makepkg option.
If they're using an install script like yaourt...I'm not going to touch
it.

I would keep the tests in your packages. I maintain the git-git package,
and it contains quite a long test suite. It's enabled because when using
development or unsupported software, you should test the crap out of it,
regardless of the length. If a user has it fails, they either risk
running likely broken sotware.

Thanks,

-- 
William Giokas | KaiSforza | http://kaictl.net/
GnuPG Key: 0x73CD09CF
Fingerprint: F73F 50EF BBE2 9846 8306  E6B8 6902 06D8 73CD 09CF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://mailman.archlinux.org/pipermail/aur-general/attachments/20131122/ba346c3c/attachment.asc>


More information about the aur-general mailing list