I agree with "a". A problem with "b" is: the user might install one of those "optional dependencies" later, but that will not trigger a rebuild of the other package and another run through the test phase. I would find "c" a bit confusing.
The most elegant way would probably be to trigger a remerge of package a, when you want to emerge package b which is also an optional dependency of package a (in case package a has a test phase ofc). But I don't see a clean and easy way to do that. On 01/06/2013 01:28 PM, Diego Elio Pettenò wrote: > Go for a. The widest and more consistent the testing, the better. > > Otherwise the day after tomorrow you'll get a bug from me that with > $foo installed, $bar fails tests. > Diego Elio Pettenò — Flameeyes > flamee...@flameeyes.eu — http://blog.flameeyes.eu/ > > > On Sun, Jan 6, 2013 at 11:38 AM, Michał Górny <mgo...@gentoo.org> wrote: >> Hello, >> >> There are some Python packages which have a bunch of optional tests >> utilizing external packages. For example, the dev-python/logilab-common >> runs a few additional tests if dev-python/egenix-mx-base is installed; >> if the package is not installed, it just skips those tests. >> >> Those tests can't be really considered 'heavy' or in any way suggesting >> use of an additional USE flag. >> >> Do you believe that the ebuilds should: >> >> a) depend on all optional test dependencies conditionally to USE=test, >> therefore always requesting the widest (and consistent) testing, >> >> b) not depend on the optional test dependencies, resulting in less >> dependencies for most users but also a bit inconsistent test >> experience, >> >> c) put the optional test dependencies behind an additional USE flag? >> >> -- >> Best regards, >> Michał Górny >
