Summary: | sys-apps/portage: clarify/fix intended behaviour of --ignore-default-opts in EMERGE_DEFAULT_OPTS | ||
---|---|---|---|
Product: | Portage Development | Reporter: | alfr0451 |
Component: | Unclassified | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | minor | CC: | david, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
alfr0451
2021-09-15 02:49:42 UTC
--ignore-default-opts does not appear to be working as described in the make.conf man page at all EMERGE_DEFAULT_OPTS Options to append to the end of the emerge(1) command line on every invocation. These options will not be appended to the com- mand line if --ignore-default-opts is specified. In fact, EMERGE_DEFAULT_OPTS are being appended to the command line even when --ignore-default-opts is specified. This is resulting in unintended behavior in particular with genkernel, since the content of EMERGE_DEFAULT_OPTS is being appended to the (default) genkernel command for rebuilding out of tree modules, despite --ignore-default-opts being present in the default @module-rebuild command line. --[no-]module-rebuild Runs, or does not run "emerge --ignore-default-opts --buildpkg=n --usepkg=n --quiet-build=y @module-rebuild" to build out-of-tree modules when possible, i.e. when non-static kernel and modules will be build, installed, --kernel-modules-prefix is not set, /var/lib/module-rebuild/moduledb exists and is not empty. So yes, please clarify/fix the intended behavior. (In reply to David K. Thompson from comment #1) Are you sure this is the same situation? Alfr's original bug was filed based on a (somewhat humourous/academic) discussion in #gentoo about specifically EMERGE_DEFAULT_OPTS="... --ignore-default-opts ..." Your issue seems to be a genkernel problem where it doesn't consistently pass --ignore-default-opts, it does some magic to try inject EMERGE_DEFAULT_OPTS by itself, or ...? What am I missing? (Even if it is related to this bug - which isn't clear right now - a test case or something would be more helpful here with details, because right now, I don't understand what's going wrong, how, or why.) I've been able to resolve my issue; i made an assumption that --ignore-default-opts and EMERGE_DEFAULT_OPTS was the culprit. I was wrong. This particular system uses binary packages ONLY, however I do build the kernel locally with genkernel and it needs to locally build the out of tree modules. Genkernel was (re)installing a binary package of xtables-addons from the build host instead of building it locally resulting in unloadable modules. It appears that setting FEATURES="getbinpkg" was my issue and interfered with the behavior of genkernels module-rebuild call. My specific workaround in genkernel.conf: MODULEREBUILD_CMD="emerge --ignore-default-opts --buildpkg=n --usepkg=n --quiet-build=y @module-rebuild --usepkg-exclude='*'" An alternative approach might have been to tell my build host to never create binary packages for kernel modules in the first place. emerge --ignore-default-opts --buildpkg=n --usepkg=n --quiet-build=y @module-rebuild -p Local copy of remote index is up-to-date and will be used. These are the packages that would be merged, in order: Calculating dependencies... done! [binary U ] net-firewall/xtables-addons-3.21 [3.20] Above is the undesired outcome. This is what I want (and now have) emerge --ignore-default-opts --buildpkg=n --usepkg=n --quiet-build=y @module-rebuild --usepkg-exclude='*' -p Local copy of remote index is up-to-date and will be used. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ] net-firewall/xtables-addons-3.21 [3.20] I'm unsure WHY --usepkg=n was insufficient. |