incus: doesn't include dependencies required for running virtual machines.

[cmspam]

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?

[cmspam]

Yeah, I've already put in a pr to update to 0.6
But it's unrelated. If you manually install the dependencies for VMs, VMs can work. I just feel it's better to automate it.

[dkwo]

splitting a incus-vm subpkg seems a good idea.

[fanyx]

you could also create a files/README.voidlinux in the base pkg to assist in understanding why VM-related tasks might not work out of the box.

then either list what packages are required for it to work
or create a subpkg that includes those dependencies

all of those could be in the PR, i believe

[classabbyamp]

optional dependencies should be specified in a README.voidlinux, not a metapackage

see steam for an example

[cmspam]

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.
https://linuxcontainers.org/incus/

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?

[classabbyamp]

don't hijack issues

[trebestie]

Sorry, it was not my intention hijacking issue.
Unfortunately since edk2-ovmf package is not available for the platform, on aarch64 incus cannot run virtual machines at all.

My regards

[cmspam]

Sorry, it was not my intention hijacking issue.
Unfortunately since edk2-ovmf package is not available for the platform, on aarch64 incus cannot run virtual machines at all.
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:
https://github.com/zabbly/incus/blob/daily/.github/workflows/builds.yml

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.

[ahesford]

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.