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

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

[cmspam]

[-- Attachment #1: Type: text/plain, Size: 1204 bytes --]

New issue by cmspam on void-packages repository

https://github.com/void-linux/void-packages/issues/49267

Description:
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 all of the dependencies needed for container management, but not for virtual machine management. Actually, using virtual machine functionality requires quite a bit of trial and error.

We can look at how other distributions handle this...

Alpine linux solves this by providing an additional [incus-vm package](https://pkgs.alpinelinux.org/package/edge/testing/x86_64/incus-vm)

The [incus spec file](https://ngompa.fedorapeople.org/for-review/incus.spec) being reviewed for inclusion into fedora uses recommends for VM-related packages.

Meanwhile the [repositories](https://github.com/zabbly/incus) 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?

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

[acidvegas]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

New comment by acidvegas on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2002059100

Comment:
I do know incus has released 0.6 and the Void package is still on 0.5.1 See this [issue](https://github.com/lxc/incus/issues/625) not sure if it's related to your issue, just figured id share because I too was having issues with incus being behind on Void.

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

[cmspam]

[-- Attachment #1: Type: text/plain, Size: 373 bytes --]

New comment by cmspam on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2002204495

Comment:
Yeah, I've already put in a [pr](https://github.com/void-linux/void-packages/pull/49265) 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.

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

[acidvegas]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

New comment by acidvegas on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2002059100

Comment:
I do know incus has released 0.6 and the Void package is still on 0.5.1 See this [issue](https://github.com/lxc/incus/issues/625) not sure if it's related to your issue, just figured id share because I too was having issues with incus being behind on Void.

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

[dkwo]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

New comment by dkwo on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2005133037

Comment:
splitting a incus-vm subpkg seems a good idea.

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

[fanyx]

[-- Attachment #1: Type: text/plain, Size: 433 bytes --]

New comment by fanyx on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2009540433

Comment:
you could also a `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

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

[fanyx]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

New comment by fanyx on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2009540433

Comment:
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

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

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 257 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2009583512

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

see steam for an example

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

[cmspam]

[-- Attachment #1: Type: text/plain, Size: 610 bytes --]

New comment by cmspam on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2016421898

Comment:
> 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?

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

[trebestie]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

New comment by trebestie on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2019023582

Comment:
I add myself to the  @cmspam's request and I'll take this thread to ask @classabbyamp, as maintainer of the edk2-ovmf package, if is there any chance to get it working on aarch64.

My kind regards

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

[trebestie]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]

New comment by trebestie on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2019023582

Comment:
I add myself to the  @cmspam's request and I'll take this thread to ask @classabbyamp, as maintainer of the edk2-ovmf package, if there is any chance to get it working on aarch64.

My kind regards

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

[classabbyamp]

[-- Attachment #1: Type: text/plain, Size: 168 bytes --]

New comment by classabbyamp on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2019027819

Comment:
don't hijack issues

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

[trebestie]

[-- Attachment #1: Type: text/plain, Size: 334 bytes --]

New comment by trebestie on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2019041255

Comment:
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

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

[cmspam]

[-- Attachment #1: Type: text/plain, Size: 2270 bytes --]

New comment by cmspam on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2019244168

Comment:
>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 good. I've had a [pull request](https://github.com/void-linux/void-packages/pull/49265) for the latest version which fixes some major issues sitting for weeks now, with no merge and no discussion of merge from maintainers. Already 6.0 has been out for nearly a month, but we're stuck at 5.1.  But on top of that, you can't get VMs working without a bunch of hoops to jump through (like the symbolic links mentioned below.) 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.

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.

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

[cmspam]

[-- Attachment #1: Type: text/plain, Size: 2261 bytes --]

New comment by cmspam on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2019244168

Comment:
>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 good. I've had a [pull request](https://github.com/void-linux/void-packages/pull/49265) 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, you can't get VMs working without a bunch of hoops to jump through (like the symbolic links mentioned below.) 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.

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.

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

[cmspam]

[-- Attachment #1: Type: text/plain, Size: 2405 bytes --]

New comment by cmspam on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2019244168

Comment:
>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 good. I've had a [pull request](https://github.com/void-linux/void-packages/pull/49265) 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.

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.

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

[cmspam]

[-- Attachment #1: Type: text/plain, Size: 2406 bytes --]

New comment by cmspam on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2019244168

Comment:
>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](https://github.com/void-linux/void-packages/pull/49265) 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.

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.

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

[cmspam]

[-- Attachment #1: Type: text/plain, Size: 2486 bytes --]

New comment by cmspam on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2019244168

Comment:
>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](https://github.com/void-linux/void-packages/pull/49265) 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.

Re: [ISSUE] [CLOSED] incus: doesn't include dependencies required for running virtual machines.

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

Closed issue by cmspam on void-packages repository

https://github.com/void-linux/void-packages/issues/49267

Description:
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](https://pkgs.alpinelinux.org/package/edge/testing/x86_64/incus-vm)

The [incus spec file](https://ngompa.fedorapeople.org/for-review/incus.spec) being reviewed for inclusion into fedora uses recommends for VM-related packages.

Meanwhile the [repositories](https://github.com/zabbly/incus) 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?

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

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 1414 bytes --]

New comment by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/49267#issuecomment-2020089155

Comment:
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.