1 |
On Wed, 03 Oct 2007 19:50:01 -0600 |
2 |
Ryan Hill <dirtyepic@g.o> wrote: |
3 |
|
4 |
> There are several packages in portage (and even in base-system) that |
5 |
> fail in src_test when userpriv/usersandbox is enabled or disabled. |
6 |
> That is, some testsuites fail when run as root and some fail if not |
7 |
> run as root. |
8 |
> |
9 |
> I'd like a simple consistent way to mark or handle these packages |
10 |
> without disabling tests altogether (RESTRICT=test). As mentioned |
11 |
> recently, checking ${FEATURES} in an ebuild is frowned upon, and it |
12 |
> doesn't seem right to handle this on a per-ebuild basis. How would |
13 |
> something like this best be implemented? A split up RESTRICT |
14 |
> (test_userpriv/test_nouserpriv)? test.eclass? Something else? |
15 |
> Looking at the bigger picture, are there any other situations where |
16 |
> finer-grained control over the test system would be helpful? |
17 |
|
18 |
See http://bugs.gentoo.org/show_bug.cgi?id=159876 for some suggestions |
19 |
for the "test-only-as-root" case. IMO ebuilds should simply test for |
20 |
the actual capabilities they need in src_test (like uid) instead of |
21 |
more abstract things like userpriv. If such tests can be used in |
22 |
several ebuilds an eclass can help to standardize them, but I don't see |
23 |
a reason to move that logic into the package manager unless those cases |
24 |
are extremely common. |
25 |
As for fine-grained user-control, it's a question of quantification as |
26 |
discussed previously, which isn't easy to solve, or you have to |
27 |
en-/disable things manually and the issue is part tf the |
28 |
per-package-env-variables problem (btw, the /etc/portage/env trick only |
29 |
works because the default src_test in ebuild.sh has the |
30 |
otherwise redundant FEATURES check which was discussed a few days ago in |
31 |
one of the commit reviews) |
32 |
|
33 |
Marius |
34 |
-- |
35 |
gentoo-dev@g.o mailing list |