The Problem ----------- I very often encounter this issue when attempting to test a package in a one-off fashion. In ideal cases, where all deps are already present for other reasons than being required by the package at hand, this works nicely with FEATURES="test" emerge -av mypackage However, if dependencies are missing, testing propagates throughout the stack. Attempts to solve this via: emerge -av --onlydeps mypackage FEATURES="test" emerge -av mypackage work, but only if there are no dedicated testing deps, or these are already present (plus this is already starting to become 2 commands for 1 operation). If the USE flag has its own dependencies and these are not already elsewise provided, both approaches above will result in the USE flag propagating throughout this missing stack segment. The slightly smarter: USE=test emerge -av --onlydeps mypackage FEATURES="test" emerge -av mypackage Will not help either. Proposed Solution ----------------- This confusion of course doesn't come out of nowhere, and I too cannot think of an easy way to sort it out using just the USE and FEATURE variables. Ideally there would be an additional command line parameter, which would simply enable testing of the listed packages and only the listed packages. Conveniently, the letter T is not yet taken: emerge -Tav mypackage
Does the emerge --with-test-deps option do what you want?
so you mean something like: emerge -v samri --with-test-deps && FEATURES=test emerge -v samri This, indeed works. I was unaware of the option. I guess I can just alias this to one command for convenience. But don't you think it makes sense to have this as a unitary function in portage? if not, what is the standalone purpose of the `--with-test-deps` option? the man page seems very brief on this.
(In reply to Horea Christian from comment #2) > so you mean something like: > > emerge -v samri --with-test-deps && FEATURES=test emerge -v samri > > This, indeed works. I was unaware of the option. I guess I can just alias > this to one command for convenience. But don't you think it makes sense to > have this as a unitary function in portage? Maybe so. However, note that this temporarily enables USE=test for the package, effectively creating a non-persistent setting that will revert the next time the package is rebuilt (possibly triggered by --changed-use or --newuse options). You can create a persistent FEATURES setting for a specific package via package.env as describe here: https://wiki.gentoo.org/wiki//etc/portage/package.env > if not, what is the standalone > purpose of the `--with-test-deps` option? the man page seems very brief on > this. A common pattern for purposes of ebuild development is to use --with-test-deps together with --onlydeps, so that the test dependencies are available when running unit tests via the ebuild(1) command.
>effectively creating a non-persistent setting that will revert the next time the >package is rebuilt (possibly triggered by --changed-use or --newuse options). When I'm debugging or testing a package in a one-off fashion (which is why I manually input the package name in the emerge command here), that sounds like pretty much exactly what I want. That is the chief problem I have with `package.env`, some tests take for ever and I certainly don't want to have them run every single time I rebuild, nor do I think it is good tp to have to toggle lines in a conf file, when a single parameter on the command line would be wholly sufficient to capture the “complexity” of the instructions.
