-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
incus: doesn't include dependencies required for running virtual machines. #49267
Comments
Yeah, I've already put in a pr to update to 0.6 |
splitting a incus-vm subpkg seems a good idea. |
you could also create a then either list what packages are required for it to work all of those could be in the PR, i believe |
optional dependencies should be specified in a README.voidlinux, not a metapackage see steam for an example |
I guess the question then, is whether VM functionality is considered optional, or core functionality. If we look at a description of what Incus is, the first sentence says "Incus is a next generation system container and virtual machine manager." Should we treat VM functionality as optional in this case? |
This comment was marked as off-topic.
This comment was marked as off-topic.
don't hijack issues |
Sorry, it was not my intention hijacking issue. My regards |
Sadly the state of Incus on void in general isn't very ideal. I've had a pull request for the latest version which fixes some major issues sitting for weeks now, with no merge and no discussion from maintainers. Already 6.0 has been out for nearly a month, but we're stuck at 5.1. But on top of that, with reference to this particular issue, you can't get VMs working without a bunch of hoops to jump through (like the symbolic links mentioned below.) (I don't think that a README will be good enough in this situation, since VMs are core functionality). I have been hoping to advance the conversation about improving this situation and having void be a first-class distro for incus. Maybe, there is not enough interest, but I think there should be, as incus is pretty fantastic software. The arm64 issue is actually something I hadn't considered, so it's good to bring up, I think. I believe this is also an issue with opensuse, and some other distributions. Actually, incus expects the OVMF files to have specific names which aren't the names used in many distributions, so symbolic links are necessary for running VMs when using the OVMF package from the repository, making it rather difficult to set up consistently at current state. We could potentially resolve some or all of these issues by doing something like zabbly does here: He actually builds OVMF for x86-64 and he builds AAVMF for aarch64. He also builds qemu. Maybe it's overkill for a void incus package, but it makes sure that all functions of incus work well, and I think there should be some interest in getting all functionality working. I maintain a docker image where I repackage zabbly's builds into a docker image, so you may be able to use it as a stop-gap until the situation on void improves. There are a lot of people much smarter than I am on here, so maybe someone will have a suggestion about the best way to proceed. I would love to see incus on void working with 100% functionality, without too much manual fixing. |
It's not about what is considered "core functionality" as advertised in the project's features, but whether the application functions without the dependencies installed. Plenty of people use incus to manage containers without needing extra dependencies for virtual machines, so we don't thrust those dependencies on every user. We don't expose optional dependencies through metapackages because there is no meaningful limit. If we don't choose one of "every combination gets a package" and "no combination gets a package", all other options will capriciously inconvenience some class of users who want to use a package with some arbitrary subset of optional dependencies. In Void, users are expected to understand how to use the software they want to install. That includes knowing that some software might have features requiring add-ons, and how to look for the pieces that are required. If there are some concerns raised by our particular packaging choices, then a "README.voidlinux" file is the preferred place to discuss those matters. If incus requires special symbolic links to find firmware files because "most distributions" don't place them where the program expects, it sounds more like incus needs to do a better job conforming to people's systems. |
Can we get the vm dependencies and configuration documented in the README.voidlinux as suggested above? |
I wanted to open a discussion about whether the maintainers of void want to do anything to handle this.
Incus is a container and virtual machine manager. Installing incus on void provides what's needed for container management, but not for virtual machine management. Actually, getting virtual machine functionality working can take quite a bit of annoying trial and error to figure out exactly what packages need to be installed.
We can look at how other distributions handle this...
Alpine linux solves this by providing an additional incus-vm package
The incus spec file being reviewed for inclusion into fedora uses recommends for VM-related packages.
Meanwhile the repositories for ubuntu/debian maintained by Stéphane Graber, have the VM-related binaries included in the incus package.
My initial thoughts are that handling it similarly to alpine wouldn't be such a bad idea, but is this something the maintainers here are interested in having implemented?
The text was updated successfully, but these errors were encountered: