Please add "modules" use flag as in pull request: https://github.com/gentoo/gentoo/pull/7543 from commit message: Global use flag "modules" activate dependancy to other packages providing kernel modules. Usually kernel and user space versions are coupled and it make sense to build both with portage. However in some circumstances the user need to manage them differently. This change add "modules" use flag enabled by default.
So the current workflow is this: 0. You have virtualbox installed and you decide you want virtualbox-modules 1. `emerge virtualbox-modules` Your proposed change gives this new workflow: 0. You have virtualbox installed and you decide you want virtualbox-modules 1. Add "app-emulation/virtualbox modules" to your local profile. 2. `emerge virtualbox`, pointlessly recompiling virtualbox and "conveniently" pulling in virtualbox-modules. Why is your two step workflow better? Note: Lots of people come up with the add-a-USE-flag-to-do-nothing-but-pull-in-another-package solution to `emerge other-package` and usually they are wrong. Documenting how one package is a good companion to another package usually is the correct solution, because how would you otherwise know what companion package to emerge?
(In reply to Jeroen Roovers from comment #1) > So the current workflow is this: > > 0. You have virtualbox installed and you decide you want virtualbox-modules > 1. `emerge virtualbox-modules` at the moment virtualbox unconditionally depends on virtualbox-modules so it's not possible to avoid virtualbox-modules if virtualbox is installed > > Your proposed change gives this new workflow: > > 0. You have virtualbox installed and you decide you want virtualbox-modules > 1. Add "app-emulation/virtualbox modules" to your local profile. > 2. `emerge virtualbox`, pointlessly recompiling virtualbox and > "conveniently" pulling in virtualbox-modules. "+modules" is default on so the workflow is more like: 0. You have virtualbox installed and you decide you DO NOT want virtualbox-modules 1. Add "app-emulation/virtualbox -modules" to your local profile. 2. `emerge virtualbox`, pointlessly recompiling virtualbox and "conveniently" /leaving out/ virtualbox-modules. > > Why is your two step workflow better? Because it add the option to install only virtualbox and not the modules. My usecase is that kernel is compiled in a different container than the one used to build virtualbox. > Note: Lots of people come up with the > add-a-USE-flag-to-do-nothing-but-pull-in-another-package solution to `emerge > other-package` and usually they are wrong. Documenting how one package is a > good companion to another package usually is the correct solution, because > how would you otherwise know what companion package to emerge? Well, in this case virtualbox is the one not being mainstream, see for example: net-vpn/wireguard sys-fs/zfs dev-util/sysdig
adding for reference the USE description for "modules" which is a global one BTW: kernel /usr/src # euse -i modules global use flags (searching: modules) ************************************************************ [+ D ] modules - Build the kernel modules local use flags (searching: modules) ************************************************************ [+ D ] modules dev-util/sysdig: Build kernel modules needed for tracing local events. Disable this only if you intend to use sysdig purely to work with dumpfiles. [+ B] 0.19.1 [gentoo] [+ B] 0.20.0 [gentoo] [+ D ] modules media-gfx/graphicsmagick: Compile graphicsmagick with dynamically loadable modules [+ ] (0/1.3) 1.3.26 [gentoo] [+ ] (0/1.3) 1.3.27 [gentoo] [+ ] (0/1.3) 1.3.28 [gentoo] [+ ] (0/9999) 9999 [gentoo] [+ D ] modules net-fs/openafs: Build libafs kernel module. Disable only if you know what you're doing: without this module OpenAFS client will not work. [+ B] 1.6.22.1 [gentoo] [+ B] 1.6.22.2 [gentoo]
Doesn't make sense to have a USE flag that only pulls in a dependency, especially for a large package that takes quite some time to compile. If you really want to manage them by hand you can use package.provided From the list, graphicsmagick does not use kernel modules, and openafs has a flag to build the modules itself, not to add a dependency. I'm inclined to close this as WONTFIX.
