New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

adding virtualbox guest support #111

Closed
wants to merge 1 commit into
base: master
from

Conversation

Projects
None yet
3 participants
@antonio-malcolm

antonio-malcolm commented Jun 11, 2017

This adds virtualbox-ose-guest to the base packages, and xrandr to the x packages, to support usage of the x86 UI environment images as virtualbox live disks.

This resolves issue #109

@Vaelatern

This comment has been minimized.

Show comment
Hide comment
@Vaelatern

Vaelatern Jun 11, 2017

Member

This is a very large package to build. Just on that I feel it might be inappropiate to add this package.

Member

Vaelatern commented Jun 11, 2017

This is a very large package to build. Just on that I feel it might be inappropiate to add this package.

@antonio-malcolm

This comment has been minimized.

Show comment
Hide comment
@antonio-malcolm

antonio-malcolm Jun 11, 2017

In comparison to what already is built into the environments?
Well, your environment-equipped live disks won't work in Virtualbox without it.
If someone wants to test Void in a VM, and/or use a live image to easily install as a VM, they will not likely be able to do so.
However, maybe no one uses or cares about this, which is fair enough.

antonio-malcolm commented Jun 11, 2017

In comparison to what already is built into the environments?
Well, your environment-equipped live disks won't work in Virtualbox without it.
If someone wants to test Void in a VM, and/or use a live image to easily install as a VM, they will not likely be able to do so.
However, maybe no one uses or cares about this, which is fair enough.

@the-maldridge

This comment has been minimized.

Show comment
Hide comment
@the-maldridge

the-maldridge Jun 11, 2017

Member

This is not an acceptable change as it breaks one path through the installer. If you boot from media with this patch and then install using the <local> source, you will wind up with the virtualbox guest extensions installed on the now physical system. There are long term plans to provide virtualization images of Void, but those are on hold pending more pressing concerns with the project.

Member

the-maldridge commented Jun 11, 2017

This is not an acceptable change as it breaks one path through the installer. If you boot from media with this patch and then install using the <local> source, you will wind up with the virtualbox guest extensions installed on the now physical system. There are long term plans to provide virtualization images of Void, but those are on hold pending more pressing concerns with the project.

@antonio-malcolm

This comment has been minimized.

Show comment
Hide comment
@antonio-malcolm

antonio-malcolm Jun 11, 2017

Ok, so it's not possible to omit the module?
Ah, nevermind. Forget it.

antonio-malcolm commented Jun 11, 2017

Ok, so it's not possible to omit the module?
Ah, nevermind. Forget it.

@antonio-malcolm antonio-malcolm deleted the antonio-malcolm:virtualbox-guest-support branch Jun 11, 2017

@antonio-malcolm antonio-malcolm restored the antonio-malcolm:virtualbox-guest-support branch Jun 11, 2017

@the-maldridge

This comment has been minimized.

Show comment
Hide comment
@the-maldridge

the-maldridge Jun 11, 2017

Member

You could remove the module, but you'd still need a post-copy step to chroot into the installed environment and remove the package.

The end goal of this PR could be solved by shipping the *.xbps files for the guest extensions and then installing them as a startup task if the machine detects that its running on a virtualized CPU. I personally think this is a huge amount of effort for not much gain, but it does solve the case where you somehow have an entire hypervisor environment, but don't have network access to the repository.

Member

the-maldridge commented Jun 11, 2017

You could remove the module, but you'd still need a post-copy step to chroot into the installed environment and remove the package.

The end goal of this PR could be solved by shipping the *.xbps files for the guest extensions and then installing them as a startup task if the machine detects that its running on a virtualized CPU. I personally think this is a huge amount of effort for not much gain, but it does solve the case where you somehow have an entire hypervisor environment, but don't have network access to the repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment