| Summary: | FEATURES=noauto should be documented in ebuild(1) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
| Component: | Current packages | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | dev-portage |
| Priority: | High | Keywords: | InVCS |
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 172589 | ||
*** This bug has been marked as a duplicate of bug 2272 *** (In reply to comment #0) > For instance, one might argue that pkg_setup() should > not be run at all if you merely request an unpack. It can be done like this: env FEATURES=noauto ebuild foo.ebuild unpack (In reply to comment #2) > (In reply to comment #0) > > For instance, one might argue that pkg_setup() should > > not be run at all if you merely request an unpack. > > It can be done like this: > > env FEATURES=noauto ebuild foo.ebuild unpack Thanks very much! Er, I was looking for just that. Now that I know the magic word "noauto", it is easy to find it in make.conf(5), whereas it is specifically intended to pertain only to ebuild and should be mentioned in ebuild(1). Furthermore, setting it in make.conf is probably never a good idea, so explaining its usage in make.conf is not a good idea either. The ebuild man page has been updated in svn r6471 and this has been released in 2.1.2.6. |
The net-dns/avahi ebuilds find certain requirements (USE flags set for other packages) as early at pkg_setup(). This means that doing an ebuild .. unpack fails on any system that has not been prepared to build net-dns/avahi on. pkg_setup() calls die() in four places when certain USE flag requirements have not been met for packages that avahi depends on. I propose that these die()s be turned into ewarn()s and that the ebuilds only really die() in src_compile, probably by doing a rather ugly duplication there. The rationale is that before src_compile(), the package is doing fine, and there is no reason to prevent a src_unpack(), so that pkg_setup() should not be (ab)used to check for possible compile issues. Feel free to re-assign this bug to portage if you feel the bug is really in the overall (e)build system. For instance, one might argue that pkg_setup() should not be run at all if you merely request an unpack. No doubt this would open us up to other huge build problems, but at least this issue would get a wider reviewing. Kind regards, JeR