Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC
Bug 651114 - app-emulation/virtualbox: add "modules" use flag
Summary: app-emulation/virtualbox: add "modules" use flag
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Lars Wendler (Polynomial-C)
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2018-03-21 20:34 UTC by Francesco Riosa
Modified: 2018-03-23 08:46 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francesco Riosa 2018-03-21 20:34:26 UTC
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.
Comment 1 Jeroen Roovers gentoo-dev 2018-03-23 07:20:45 UTC
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?
Comment 2 Francesco Riosa 2018-03-23 08:41:15 UTC
(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
Comment 3 Francesco Riosa 2018-03-23 08:46:38 UTC
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]