Summary: | Add emerge `-T` parameter to enable testing the package list exclusively. This prevents USE="test" propagation to testing dependencies. | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Horea Christian <gentoo> |
Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=561406 https://bugs.gentoo.org/show_bug.cgi?id=650568 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 912975 |
Description
Horea Christian
2019-01-12 20:45:51 UTC
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.
|