For normal users we wouldn't. But currently, arch-testers need to make a
judgement call on what to test when a stable-req bug is filed. Tests run in
src_test are provided by upstream, and does not guarantee that a package
that has been merged will actually run on the system.
If the maintainer could add a couple small scripts to check basic
functionality
of the merged package, it would make testing for arch testers much easier
and reliable.
Let me give an example. Let's say
app-misc/screenfetch-2.7.7 is the current stable package for screenfetch in
the portage tree.
However, on running, it produces an error on the top, along with the proper
output.
If screenfetch-3.0.0 happens to fix that error, maintainer can add a simple
script
if [ "$(screenfetch 2>&1 1>/dev/null)" != "" ] then
eerror "Still producing error"
fi
To make sure the build is properly updating the screenfetch version, and
that
the bug has in fact been fixed. This is the only way I can see to reliabily
and automatically test packages that have been merged successfully.
-------
Regards,
Pallav
On Mon, May 16, 2016 at 10:08 PM, Luis Ressel <ara...@aixah.de> wrote:
> On Mon, 16 May 2016 18:13:33 +0530
> Pallav Agarwal <pallavagarwa...@gmail.com> wrote:
>
> > What I'm suggesting is to add a new function post_install_test. The
> > function will run only if the build is being run for stabilization
> > (either as a part of automated stabilization, or manual) which can be
> > controlled by a USE flag. The function would also require independent
> > dependencies in case it uses external applications to test the one
> > being built.
>
> Could you please elaborate on this? We already have src_test() for
> automated tests. Why would we want to run additional tests after the
> package has been merged?
>
> --
> Regards,
> Luis Ressel
>
> Luis Ressel <ara...@aixah.de>
> GPG fpr: F08D 2AF6 655E 25DE 52BC E53D 08F5 7F90 3029 B5BD
>
