[arch-dev-public] DKMS modules for virtualbox
Why are we no longer shipping virtualbox modules pre-build? What are the advantages from a user perspective? Is this happening for any other modules? Bad things I see: 1) pre pacman-5.0 updates unsupported without any prior notification 2) notification of need for linux headers is only given (optional dep) in update that needs them for building. There is no reason given why they are optional dependencies. There is no notification that the build did not go ahead at the end of the transaction. 3) Update is now a lot slower (and this is repeated over a lot of users) 4) additional download/install size (linux headers + module source). Is there a single advantage for our *users* using the two kernels in [core]? Allan
On 2016-03-06 12:41, Allan McRae wrote:
Why are we no longer shipping virtualbox modules pre-build? What are the advantages from a user perspective? Is this happening for any other modules?
Bad things I see: 1) pre pacman-5.0 updates unsupported without any prior notification 2) notification of need for linux headers is only given (optional dep) in update that needs them for building. There is no reason given why they are optional dependencies. There is no notification that the build did not go ahead at the end of the transaction. 3) Update is now a lot slower (and this is repeated over a lot of users) 4) additional download/install size (linux headers + module source).
Is there a single advantage for our *users* using the two kernels in [core]?
Allan
5) As an end user, I don't want to have compiler or kernel headers installed. Bartłomiej
On Sun, Mar 6, 2016 at 12:44 PM, Bartłomiej Piotrowski < bpiotrowski@archlinux.org> wrote:
5) As an end user, I don't want to have compiler or kernel headers installed.
^ This. -- Andrea
On 07/03/16 18:51, Andrea Scarpino wrote:
On Sun, Mar 6, 2016 at 12:44 PM, Bartłomiej Piotrowski < bpiotrowski@archlinux.org> wrote:
5) As an end user, I don't want to have compiler or kernel headers installed.
^ This.
Is the virtualbox maintainer going to comment on this thread and justify the use of dkms? A
On March 8, 2016 11:16:55 AM GMT+01:00, Allan McRae <allan@archlinux.org> wrote:
On 07/03/16 18:51, Andrea Scarpino wrote:
On Sun, Mar 6, 2016 at 12:44 PM, Bartłomiej Piotrowski < bpiotrowski@archlinux.org> wrote:
5) As an end user, I don't want to have compiler or kernel headers installed.
^ This.
Is the virtualbox maintainer going to comment on this thread and justify the use of dkms?
A
Yes he will. The early move of virtualbox from cty-testing to cty didn't schedule well with my free time. Will answer this evening. Cheers, -- Sébastien "Seblu" Luttringer Sent from my phone, please excuse typo and brevity.
On dim., 2016-03-06 at 21:41 +1000, Allan McRae wrote:
Before going technical, I want to make a quick summary of what happened so far. Earlier in February, I started a thread on this ml about improving our "out of tree modules" management with dkms. My planned final step[1] was to let vbox rely on this solution and so drop the binary modules. I pushed a vbox package in testing and feedback was requested. 8 days later, the openssl rebuild came up and moved vbox to community. This pushed vbox out of testing a bit too fast (no message, no enough test). So we are now.
What are the advantages from a user perspective? Have all its vbox modules the same way whatever kernel it uses (-arch, -lts, -grsec, -zen-, -custom).
Why are we no longer shipping virtualbox modules pre-build? It removes the sync burden of kernel upgrades and its modules upgrades from the maintainers. Knowing that I have a 512Kbit/s connection at home, that not nothing to me.
Is this happening for any other modules? In my knowledge, there is no global plan. Even I would like have all our binary modules have its -dkms counterpart to properly handle each kernel flavours.
Currently, we have both kind of modules in our repo. ndiswrapper is provided with no binary and bbswitch is only binary. So both way seems acceptable.
Bad things I see: 1) pre pacman-5.0 updates unsupported without any prior notification Interesting. This issue will also be present if we move other stuff like update-desktop-database to hooks, right? Do we have a way to detect pre-pacman 5 update to display a warning or handle it correctly?
2) notification of need for linux headers is only given (optional dep) in update that needs them for building. There is no reason given why they are optional dependencies. There is no notification that the build did not go ahead at the end of the transaction. I agree, this is not good, but this is not something new for users of dkms packages. dkms modules never pull a particular version of the kernel headers because there is no reason to deps on linux-headers more than linux-lts-header, linux-zen-headers, linux-grsec-headers. What we want is to pull at least one kernel header.
A bug report[2] was opened, and I hope we will find a solution with kernel maintainers to request kernel headers to be present not depending on the flavor. I will add a message in the dkms alpm hook to notify when kernel headers are missing and prevent module installation when only headers are present (causing issue with later kernel installation).
3) Update is now a lot slower and this is repeated over a lot of users) 4) additional download/install size (linux headers + module source). 5) I don't want to have compiler or kernel headers installed.
I acknowledge that. I like the idea of having several flavor of the Linux kernel inside Arch Linux and I would like we have a proper support of out-of-tree-modules for all of them. Moreover, I hope we will introduce versioned kernel to fix the kernel upgrade which remove the current running modules or break the boot. All of this will multiply the complexity of the sync between binary modules and the kernel release for packages maintainers. As we currently not have the infrastructure to build binaries modules each time a new kernel version (flavoured / versioned) is pushed, dkms seems a good trade-off if we want to move forward this way. So, even I think we should not, I'm not against having binary modules for vbox in cty, but I would use dkms as default and let the maintainer of the binary modules handle them. Cheers, [1] https://lists.archlinux.org/pipermail/arch-dev-public/2016-February/027770. html [2] https://bugs.archlinux.org/task/48498 -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On 09/03/16 09:29, Sébastien Luttringer wrote:
On dim., 2016-03-06 at 21:41 +1000, Allan McRae wrote:
Before going technical, I want to make a quick summary of what happened so far. Earlier in February, I started a thread on this ml about improving our "out of tree modules" management with dkms. My planned final step[1] was to let vbox rely on this solution and so drop the binary modules. I pushed a vbox package in testing and feedback was requested. 8 days later, the openssl rebuild came up and moved vbox to community. This pushed vbox out of testing a bit too fast (no message, no enough test). So we are now.
What are the advantages from a user perspective? Have all its vbox modules the same way whatever kernel it uses (-arch, -lts, -grsec, -zen-, -custom).
Why are we no longer shipping virtualbox modules pre-build? It removes the sync burden of kernel upgrades and its modules upgrades from the maintainers. Knowing that I have a 512Kbit/s connection at home, that not nothing to me.
All users of virtualbox-host-modules now have to download 350x more to update the modules for each kernel update. In fact, it is worse than that, because some kernel updates do not require module rebuilds but will have a new headers package.
Is this happening for any other modules? In my knowledge, there is no global plan. Even I would like have all our binary modules have its -dkms counterpart to properly handle each kernel flavours.
Currently, we have both kind of modules in our repo. ndiswrapper is provided with no binary and bbswitch is only binary. So both way seems acceptable.
Bad things I see: 1) pre pacman-5.0 updates unsupported without any prior notification Interesting. This issue will also be present if we move other stuff like update-desktop-database to hooks, right? Do we have a way to detect pre-pacman 5 update to display a warning or handle it correctly?
There needs to be a public announcement made that we expected everyone to have updated to pacman-5.0 by <insert date here>. Then we start using hooks.
2) notification of need for linux headers is only given (optional dep) in update that needs them for building. There is no reason given why they are optional dependencies. There is no notification that the build did not go ahead at the end of the transaction. I agree, this is not good, but this is not something new for users of dkms packages. dkms modules never pull a particular version of the kernel headers because there is no reason to deps on linux-headers more than linux-lts-header, linux-zen-headers, linux-grsec-headers. What we want is to pull at least one kernel header.
A bug report[2] was opened, and I hope we will find a solution with kernel maintainers to request kernel headers to be present not depending on the flavor.
I will add a message in the dkms alpm hook to notify when kernel headers are missing and prevent module installation when only headers are present (causing issue with later kernel installation).
That will fix the use of "optdepends" for things that are not optional (this is not the only package that does this...)
3) Update is now a lot slower and this is repeated over a lot of users) 4) additional download/install size (linux headers + module source). 5) I don't want to have compiler or kernel headers installed.
I acknowledge that.
I like the idea of having several flavor of the Linux kernel inside Arch Linux and I would like we have a proper support of out-of-tree-modules for all of them. Moreover, I hope we will introduce versioned kernel to fix the kernel upgrade which remove the current running modules or break the boot. All of this will multiply the complexity of the sync between binary modules and the kernel release for packages maintainers.
As we currently not have the infrastructure to build binaries modules each time a new kernel version (flavoured / versioned) is pushed,
Surely that is a five line script...
dkms seems a good trade-off if we want to move forward this way.
So, even I think we should not, I'm not against having binary modules for vbox in cty, but I would use dkms as default and let the maintainer of the binary modules handle them.
We are not a source based distribution. Binary packages should be the default. I have no objection to dkms versions being present (I believe they have been for a while). I only object to not having binary modules by default for our primary kernels (i.e. the ones in [core]) A
On mer., 2016-03-09 at 10:19 +1000, Allan McRae wrote:
On 09/03/16 09:29, Sébastien Luttringer wrote:
1) pre pacman-5.0 updates unsupported without any prior notification Interesting. This issue will also be present if we move other stuff like update-desktop-database to hooks, right? Do we have a way to detect pre-
On dim., 2016-03-06 at 21:41 +1000, Allan McRae wrote: pacman 5 update to display a warning or handle it correctly?
There needs to be a public announcement made that we expected everyone to have updated to pacman-5.0 by <insert date here>. Then we start using hooks. There is no way without breaking people updating their Arch from pacman 4.x after that random date?
We are not a source based distribution. Debian provides its vbox modules only via dkms and it's not a source distribution (as far I know).
Not to mention, that we are not providing binary modules for all our kernels, or all our modules in binary for months and we are stil not a source distribution.
Binary packages should be the default. It also elegant to default to a package which works with all kernels.
As we currently not have the infrastructure to build binaries modules each time a new kernel version (flavoured / versioned) is pushed, Surely that is a five line script... Please provide it. We are building all our kernel modules manually for years.
How this will work? When I push a new version of virtualbox on svn a builder will pick the current kernel and build the modules from my dkms version and push them to the repo? Which key will sign these packages? How this will be synced with db-update? We will even be able to provide binary modules for all kernel we have in core and in cty without much effort. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On 09/03/16 11:44, Sébastien Luttringer wrote:
On mer., 2016-03-09 at 10:19 +1000, Allan McRae wrote:
On 09/03/16 09:29, Sébastien Luttringer wrote:
On dim., 2016-03-06 at 21:41 +1000, Allan McRae wrote:
1) pre pacman-5.0 updates unsupported without any prior notification
Interesting. This issue will also be present if we move other stuff like update-desktop-database to hooks, right? Do we have a way to detect pre- pacman 5 update to display a warning or handle it correctly?
There needs to be a public announcement made that we expected everyone to have updated to pacman-5.0 by <insert date here>. Then we start using hooks. There is no way without breaking people updating their Arch from pacman 4.x after that random date?
That is the only way. Joys of rolling release.
We are not a source based distribution. Debian provides its vbox modules only via dkms and it's not a source distribution (as far I know).
Not to mention, that we are not providing binary modules for all our kernels, or all our modules in binary for months and we are stil not a source distribution.
Binary packages should be the default. It also elegant to default to a package which works with all kernels.
As we currently not have the infrastructure to build binaries modules each time a new kernel version (flavoured / versioned) is pushed, Surely that is a five line script... Please provide it. We are building all our kernel modules manually for years.
How this will work? When I push a new version of virtualbox on svn a builder will pick the current kernel and build the modules from my dkms version and push them to the repo? Which key will sign these packages? How this will be synced with db-update?
What has pushing a new version of virtualbox got to do with rebuilding modules when the kernel is updated? Rebuilding modules on kernel update is: for pkg in <module package list>; do archco <pkg> // awk/sed line to bump pkgrel testing-x86_64-build && testing-i686-build testingpkg "module rebuild" done OK - I was wrong. That is six lines (or seven if you count the line with && as two lines...).
We will even be able to provide binary modules for all kernel we have in core and in cty without much effort.
Cheers,
On mer., 2016-03-09 at 12:10 +1000, Allan McRae wrote:
On 09/03/16 11:44, Sébastien Luttringer wrote:
On mer., 2016-03-09 at 10:19 +1000, Allan McRae wrote:
On 09/03/16 09:29, Sébastien Luttringer wrote:
On dim., 2016-03-06 at 21:41 +1000, Allan McRae wrote:
1) pre pacman-5.0 updates unsupported without any prior notification
Interesting. This issue will also be present if we move other stuff like update-desktop-database to hooks, right? Do we have a way to detect pre- pacman 5 update to display a warning or handle it correctly?
There needs to be a public announcement made that we expected everyone to have updated to pacman-5.0 by <insert date here>. Then we start using hooks.
There is no way without breaking people updating their Arch from pacman 4.x after that random date?
That is the only way. Joys of rolling release.
If pacman was able to update itself first, as it does before, this would, rolling release or not, do the job?
As we currently not have the infrastructure to build binaries modules each time a new kernel version (flavoured / versioned) is pushed, Surely that is a five line script... Please provide it. We are building all our kernel modules manually for years.
How this will work? When I push a new version of virtualbox on svn a builder will pick the current kernel and build the modules from my dkms version and push them to the repo? Which key will sign these packages? How this will be synced with db-update? What has pushing a new version of virtualbox got to do with rebuilding modules when the kernel is updated? Rebuilding modules on kernel update is:
for pkg in <module package list>; do archco <pkg> // awk/sed line to bump pkgrel testing-x86_64-build && testing-i686-build testingpkg "module rebuild" done
OK - I was wrong. That is six lines (or seven if you count the line with && as two lines...).
We are definitely not talking of the same thing. I was talking of an automated way of building o-o-t modules when the dkms package is updated or the kernel is bumped. Was you are proposing, is what I referred as manually.
== Before going further, keep in mind that I'm open to bring back pre-built modules for virtualbox. But currently there is no rules and no coherence between our way of doing. Let me summarise the situation with the following table: | package name | linux | linux-lts | dkms | | acpi_call | yes | yes | no | | bbswitch | yes | yes | no | | nvidia | yes | yes | yes | | nvidia-340xx | yes | yes | yes | | nvidia-304xx | yes | yes | yes | | ndiswrapper-dkms | no | no | yes | | r8168 | yes | yes | no | | rt3562sta | yes | no | no | | sysdig | no | no | yes | | vhba-module | yes | no | no | | virtualbox-host-modules | no | no | yes | | virtualbox-guest-modules | no | no | yes | So, each maintainer do what he wants. Please note that as an ideal target, I would have all our kernel modules available via dkms _and_ via prebuilt modules for each kernel flavor we provide. I read on the dev IRC that few modules could only be shipped from sources. Not sure of that btw. For example, we could, for simplicity says that we provide pre-built modules only for the main kernel and dkms for all others kernels. What I would like is a team consensus/decision on how we handle kernel oot modules not complains directed on virtualbox only. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
<snip> I feel the most tedious part of being kernel maintainer is doing the rebuilds of third party modules I don't personally care about. IMHO we should have DKMS for all external modules, and then use strict dependency versioning for packaged binary modules, so it becomes package (not kernel) maintainer responsibility to rebuild it. Bartłomiej
On 13/03/16 23:25, Bartłomiej Piotrowski wrote:
<snip>
I feel the most tedious part of being kernel maintainer is doing the rebuilds of third party modules I don't personally care about. IMHO we should have DKMS for all external modules, and then use strict dependency versioning for packaged binary modules, so it becomes package (not kernel) maintainer responsibility to rebuild it.
If it is the packagers responsibility to rebuild kernel modules, they should always go to [staging] first. A
On 13/03/16 00:52, Sébastien Luttringer wrote:
Please note that as an ideal target, I would have all our kernel modules available via dkms _and_ via prebuilt modules for each kernel flavor we provide. I read on the dev IRC that few modules could only be shipped from sources. Not sure of that btw.
For example, we could, for simplicity says that we provide pre-built modules only for the main kernel and dkms for all others kernels.
What I would like is a team consensus/decision on how we handle kernel oot modules not complains directed on virtualbox only.
I vote for binary modules for all kernels in [core] and dkms versions. Kernels outside of [core] can have binary modules provided at the maintainer's choice. A
On 14/03/16 09:07, Allan McRae wrote:
On 13/03/16 00:52, Sébastien Luttringer wrote:
Please note that as an ideal target, I would have all our kernel modules available via dkms _and_ via prebuilt modules for each kernel flavor we provide. I read on the dev IRC that few modules could only be shipped from sources. Not sure of that btw.
For example, we could, for simplicity says that we provide pre-built modules only for the main kernel and dkms for all others kernels.
What I would like is a team consensus/decision on how we handle kernel oot modules not complains directed on virtualbox only.
I vote for binary modules for all kernels in [core] and dkms versions. Kernels outside of [core] can have binary modules provided at the maintainer's choice.
We are going to need more opinions here to build a consensus... A
On Tue, Mar 15, 2016 at 1:06 AM, Allan McRae <allan@archlinux.org> wrote:
On 14/03/16 09:07, Allan McRae wrote:
On 13/03/16 00:52, Sébastien Luttringer wrote:
Please note that as an ideal target, I would have all our kernel modules available via dkms _and_ via prebuilt modules for each kernel flavor we provide. I read on the dev IRC that few modules could only be shipped from sources. Not sure of that btw.
For example, we could, for simplicity says that we provide pre-built modules only for the main kernel and dkms for all others kernels.
What I would like is a team consensus/decision on how we handle kernel oot modules not complains directed on virtualbox only.
I vote for binary modules for all kernels in [core] and dkms versions. Kernels outside of [core] can have binary modules provided at the maintainer's choice.
We are going to need more opinions here to build a consensus...
A
Having used the ck kernel for years, and now zen, I am somehow biased and in favor of DKMS everywhere, that and it really puts a burden on our kernel maintainers having to build all our OOT modules with every upgrade. It really doesn't take that much time to build them, even on modest machines (got nvidia, bbswitch, vboxhost and cdemu on my laptop). Also I know some people disagree, but kernel headers don't take that much space, bandwidth may be another story though. That being said, I feel that what Sebastien proposed, ie having built modules only for linux and linux-lts, and DKMS everywhere else would be a good compromise IMHO. Cheers, -- Maxime
On 15.03.2016 08:26, Maxime Gauduin wrote:
It really doesn't take that much time to build them, even on modest machines (got nvidia, bbswitch, vboxhost and cdemu on my laptop).
I really feel like vbox takes way too long to build. It's probably not longer than 15 seconds, but it produces so much output that it feels slow (well and because it is when compared to how fast the archive would be extracted).
That being said, I feel that what Sebastien proposed, ie having built modules only for linux and linux-lts, and DKMS everywhere else would be a good compromise IMHO.
Please go that route. We are a binary distro and I'd prefer to have as many packages prebuilt as possible. I'm always reminded of that when I build perl modules from cpan. Installing 20 modules from the repos is done in like 10 seconds while building them takes something like 1 to 10 minutes (yay tests). Florian
On 15 March 2016 at 01:06, Allan McRae <allan@archlinux.org> wrote:
On 14/03/16 09:07, Allan McRae wrote:
I vote for binary modules for all kernels in [core] and dkms versions. Kernels outside of [core] can have binary modules provided at the maintainer's choice.
We are going to need more opinions here to build a consensus...
A
While I like the idea of having DKMS in the repo, I'm strongly in favor of having binary modules for kernels from [core] Lukas
On 15.03.2016 01:06, Allan McRae wrote:
On 14/03/16 09:07, Allan McRae wrote:
On 13/03/16 00:52, Sébastien Luttringer wrote:
Please note that as an ideal target, I would have all our kernel modules available via dkms _and_ via prebuilt modules for each kernel flavor we provide. I read on the dev IRC that few modules could only be shipped from sources. Not sure of that btw.
For example, we could, for simplicity says that we provide pre-built modules only for the main kernel and dkms for all others kernels.
What I would like is a team consensus/decision on how we handle kernel oot modules not complains directed on virtualbox only.
I vote for binary modules for all kernels in [core] and dkms versions. Kernels outside of [core] can have binary modules provided at the maintainer's choice.
We are going to need more opinions here to build a consensus...
A
I agree. There is no point in having every user building the exact same module on every update. That's why we package precompiled packages. This looks more like a workaround of how kernel and module updates are handled atm. E.g. the kernel stays in testing for a long time and is not put into staging first so packagers can rebuild their modules. Greetings, Pierre -- Pierre Schmitz, https://pierre-schmitz.com
[2016-03-15 10:06:22 +1000] Allan McRae:
On 14/03/16 09:07, Allan McRae wrote:
On 13/03/16 00:52, Sébastien Luttringer wrote:
Please note that as an ideal target, I would have all our kernel modules available via dkms _and_ via prebuilt modules for each kernel flavor we provide. I read on the dev IRC that few modules could only be shipped from sources. Not sure of that btw.
For example, we could, for simplicity says that we provide pre-built modules only for the main kernel and dkms for all others kernels.
What I would like is a team consensus/decision on how we handle kernel oot modules not complains directed on virtualbox only.
I vote for binary modules for all kernels in [core] and dkms versions. Kernels outside of [core] can have binary modules provided at the maintainer's choice.
We are going to need more opinions here to build a consensus...
To me the issue is people pushing new kernels to the repos but not being able to provide the same level of support that we have for mainline. Offloading out-of-tree module rebuilds to end users instead of doing it ourselves is clearly not the right solution. So I say: remove each non-mainline kernel of which the maintainer is unwilling to support the corresponding out-of-tree modules. After all, as Allan points out, rebuilding them is a simple script job... Cheers. -- Gaetan
To me the issue is people pushing new kernels to the repos but not being able to provide the same level of support that we have for mainline. Offloading out-of-tree module rebuilds to end users instead of doing it ourselves is clearly not the right solution.
So I say: remove each non-mainline kernel of which the maintainer is unwilling to support the corresponding out-of-tree modules. After all, as Allan points out, rebuilding them is a simple script job...
Cheers.
In general, out-of-tree modules aren't compatible with linux-grsec. It is not enough to simply rebuild them. It would require actively keeping them compatible by maintaining patches for them and possibly working with the upstreams for the out-of-tree modules for cases where bugs are being uncovered rather than false positives / tweaks for compatibility. Some out-of-tree modules aren't going to be compatible with the chosen configuration at all, similar to how Xen support is disabled in favour of having the hardening features marked as incompatible with it. The NVIDIA driver and broadcom-wl need to be patched and and VirtualBox is semi-incompatible with the chosen configuration. AFAIK, users would need to rebuild the kernel with a couple options disabled for all the VirtualBox features to work.
[2016-03-15 19:49:25 -0400] Daniel Micay:
To me the issue is people pushing new kernels to the repos but not being able to provide the same level of support that we have for mainline. Offloading out-of-tree module rebuilds to end users instead of doing it ourselves is clearly not the right solution.
So I say: remove each non-mainline kernel of which the maintainer is unwilling to support the corresponding out-of-tree modules. After all, as Allan points out, rebuilding them is a simple script job...
Cheers.
In general, out-of-tree modules aren't compatible with linux-grsec. It is not enough to simply rebuild them. It would require actively keeping them compatible by maintaining patches for them and possibly working with the upstreams for the out-of-tree modules for cases where bugs are being uncovered rather than false positives / tweaks for compatibility.
Some out-of-tree modules aren't going to be compatible with the chosen configuration at all, similar to how Xen support is disabled in favour of having the hardening features marked as incompatible with it.
The NVIDIA driver and broadcom-wl need to be patched and and VirtualBox is semi-incompatible with the chosen configuration. AFAIK, users would need to rebuild the kernel with a couple options disabled for all the VirtualBox features to work.
So linux-grsec supports no out-of-tree module? No requirement on dkms for it, then. Fine by me. -- Gaetan
So linux-grsec supports no out-of-tree module? No requirement on dkms for it, then. Fine by me.
NVIDIA is the one of the few that would make sense because the PaX upstream actually maintains a patch for it: https://www.grsecurity.net/~paxguy1/nvidia-drivers-361.28-pax.patch If I was going to package it, I would definitely avoid DKMS. DKMS doesn't interact well with grsecurity. The modules need to be built with the same GCC used to compile the kernel. There are GCC plugins and the GCC ABI varies based on version and configuration (i.e. gcc-multilib won't work either). It's not really the same thing as repackaging the nvidia driver for another kernel though. I'll end up having to update the patch myself when it breaks because I'll be one of the first people trying to use it when I rebuild nvidia-grsec after linux-grsec. I just haven't felt like taking on that responsibility.
Having given everyone time to reply (not that many did...), the consensus of those that replied is: - Binary modules are to be provided at minimum of all kernels in [core], with preference to providing them for all supported kernels (noting that out-of-tree modules may not work with some patched kernels). - There is no objection to providing DKMS modules in the repos, but this is secondary to binary modules. No opinions were stated on whether we ensure all modules have DKMS variants in the repos. I decree by the power invested in me through talking the loudest, that this is now our policy. Allan
On mer., 2016-03-23 at 13:08 +1000, Allan McRae wrote:
Having given everyone time to reply (not that many did...), the consensus of those that replied is:
- Binary modules are to be provided at minimum of all kernels in [core], with preference to providing them for all supported kernels (noting that out-of-tree modules may not work with some patched kernels).
- There is no objection to providing DKMS modules in the repos, but this is secondary to binary modules. No opinions were stated on whether we ensure all modules have DKMS variants in the repos.
I decree by the power invested in me through talking the loudest, that this is now our policy.
Unexpectedly we got the most feedback from persons who are not dealing currently with the burden of managing kernels and their modules. Like you I was expecting more opinions. Even I support your will of moving forward regarding all this discussion, I don't share your conclusions nor the fact that one of us could speak lourder to impose his will to others. I have few more subjects to discuss altogether where I hope we could take team directions by constructive discussions and not decree. == I give a second read to all emails exchanged since my original one about o-o-t- m at 19th February and I come to this: 1) No one support that we should manage kernels differently because they are under different repository. ==> We must manage them all the same way. 2) No one object to a module exclusion from a specific kernel when it make no sense Examples was provided with GRSEC. ==> We could exclude modules support for a kernel for technical reasons. 3) There is a consensus on having binary modules in our repositories. ==> We must provides binary modules for all kernels. Except those covered by 2. 4) No one object to having dkms available for all modules; It's even supported by several fellows and this is offering support for AUR and custom kernels at almost no maintenance cost. ==> We must provides dkms build for all modules. Except those covered by 2. 5) There is no much discussion about which should be the default (a binary flavor or dkms). I would propose a solution which let the user choose which module he want needs by pulling a defined dep like module-$modulename. ==> Applications should pull a generic deps to let users decide which module he wants (flavored or dkms). 6) Binary modules should be built from the dkms package. This was not discussed earlier, but I see a benefits to have a common way of building modules and testing the dkms package in one row. 7) https://bugs.archlinux.org/task/48498 ==> kernels packages should provides kernel=$version and kernel- headers=$version in order to let dkms modules maintainers require at least a kernel and its header to be installed. This is the policy I propose we adopt. Note that this policy is not defining who is responsible of what. We could keep our current way of doing. I mean: - When a kernel is upgraded, it's kernel maintainer responsibility to upgrade all binary modules - When a module is upgraded, it's the modules maintainer responsibility to build the module for all kernels in stable and in testing (This is boring). Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On 24/03/16 07:28, Sébastien Luttringer wrote:
On mer., 2016-03-23 at 13:08 +1000, Allan McRae wrote:
Having given everyone time to reply (not that many did...), the consensus of those that replied is:
- Binary modules are to be provided at minimum of all kernels in [core], with preference to providing them for all supported kernels (noting that out-of-tree modules may not work with some patched kernels).
- There is no objection to providing DKMS modules in the repos, but this is secondary to binary modules. No opinions were stated on whether we ensure all modules have DKMS variants in the repos.
I decree by the power invested in me through talking the loudest, that this is now our policy.
Unexpectedly we got the most feedback from persons who are not dealing currently with the burden of managing kernels and their modules. Like you I was expecting more opinions.
Even I support your will of moving forward regarding all this discussion, I don't share your conclusions nor the fact that one of us could speak lourder to impose his will to others.
It was a joke. Although those of us that have been around here 10 years have loud voices...
I have few more subjects to discuss altogether where I hope we could take team directions by constructive discussions and not decree.
==
I give a second read to all emails exchanged since my original one about o-o-t- m at 19th February and I come to this:
1) No one support that we should manage kernels differently because they are under different repository. ==> We must manage them all the same way.
I did. Maxime said building modules for only linux and linux-lts is a good compromise. The Florian said "please go that route". Lukas was strongly in favour "of have binary modules for kernels from [core]". Gatean was in favour of having all kernels support binary modules. Hence my conclusion: "Binary modules are to be provided at minimum of all kernels in [core], with preference to providing them for all supported kernels (noting that out-of-tree modules may not work with some patched kernels)."
2) No one object to a module exclusion from a specific kernel when it make no sense Examples was provided with GRSEC. ==> We could exclude modules support for a kernel for technical reasons.
Hence the "noting that out-of-tree modules may not work with some patched kernels" in my conclusion.
3) There is a consensus on having binary modules in our repositories. ==> We must provides binary modules for all kernels. Except those covered by 2.
See 1).
4) No one object to having dkms available for all modules; It's even supported by several fellows and this is offering support for AUR and custom kernels at almost no maintenance cost. ==> We must provides dkms build for all modules. Except those covered by 2.
As I said, no-one objected to DKMS modules. But no opinions were stated whether they must be provided.
5) There is no much discussion about which should be the default (a binary flavor or dkms). I would propose a solution which let the user choose which module he want needs by pulling a defined dep like module-$modulename. ==> Applications should pull a generic deps to let users decide which module he wants (flavored or dkms).
REALLY? You need to read that thread again. Default binary was strongly supported.
6) Binary modules should be built from the dkms package. This was not discussed earlier, but I see a benefits to have a common way of building modules and testing the dkms package in one row.
Not part of the discussion. The maintainers of the packages can have a separate discussion about this.
7) https://bugs.archlinux.org/task/48498 ==> kernels packages should provides kernel=$version and kernel- headers=$version in order to let dkms modules maintainers require at least a kernel and its header to be installed.
Off-topic for this discussion.
This is the policy I propose we adopt.
Note that this policy is not defining who is responsible of what. We could keep our current way of doing. I mean: - When a kernel is upgraded, it's kernel maintainer responsibility to upgrade all binary modules
It already is, unless they put the package in [staging] and create a rebuild list. Same as every other package.
- When a module is upgraded, it's the modules maintainer responsibility to build the module for all kernels in stable and in testing (This is boring).
It already is. If you don't like doing it, don't maintain the package. A
Am Thu, 24 Mar 2016 08:29:57 +1000 schrieb Allan McRae <allan@archlinux.org>:
I did. Maxime said building modules for only linux and linux-lts is a good compromise. The Florian said "please go that route". Lukas was strongly in favour "of have binary modules for kernels from [core]".
Gatean was in favour of having all kernels support binary modules.
Hence my conclusion:
"Binary modules are to be provided at minimum of all kernels in [core], with preference to providing them for all supported kernels (noting that out-of-tree modules may not work with some patched kernels)."
Building binary modules for LTS kernel is no big task and takes me 15 minutes when they break. The real work is done in the mainline vanilla kernel (tpowa and module package maintainers). I'm fine with providing binary modules as long as this is an easy task for me to keep them building. I see dkms more something for custom kernels and such stuff. I see no need to have this in core or extra repo. There's no real advantage for the user experience over binary modules. Community repo would be fine for users who prefer to play with dkms stuff if not AUR. -Andy
On jeu., 2016-03-24 at 08:29 +1000, Allan McRae wrote:
On 24/03/16 07:28, Sébastien Luttringer wrote:
On mer., 2016-03-23 at 13:08 +1000, Allan McRae wrote: 1) No one support that we should manage kernels differently because they are under different repository. ==> We must manage them all the same way.
I did.
Maxime said building modules for only linux and linux-lts is a good compromise. Maxime says exactly: "I feel that what Sebastien proposed, ie having built modules only for linux and linux-lts, and DKMS everywhere else would be a good compromise IMHO."
Unfortunately, I never proposed linux-lts, it was you. So, I asked you the reason on IRC: [2016-03-21 20:32:47] <seblu> amcrae: why do you want to manage core kernels differently than others? And moreover, who cares of -lts nowdays? [2016-03-21 23:50:44] <amcrae> seblu: I don't want to manage core kernels different - preferably all kernels are provided with binary modules Reading this, and as you were behind the "core kernels" group, I was expecting you conclude to binary module for the arch kernel, dkms for the rest. Which is not coherent with the "we are a binary distro", but a common ground.
4) No one object to having dkms available for all modules; It's even supported by several fellows and this is offering support for AUR and custom kernels at almost no maintenance cost. ==> We must provides dkms build for all modules. Except those covered by 2. As I said, no-one objected to DKMS modules. But no opinions were stated whether they must be provided.
I did, and Maxime: "I am somehow biased and in favor of DKMS everywhere" Florian: "Please go that route" (the route also refer to DKMS everywhere). Bartłomiej: "IMHO we should have DKMS for all external modules" Lukas: "I like the idea of having DKMS in the repo"
5) There is no much discussion about which should be the default (a binary flavor or dkms). I would propose a solution which let the user choose which module he want needs by pulling a defined dep like module-$modulename. ==> Applications should pull a generic deps to let users decide which module he wants (flavored or dkms). REALLY? You need to read that thread again. Default binary was strongly supported.
Yes, binaries are preferred, that was not my point. The keyword was flavor. For example, vbox was pulling the binary modules for the -arch kernel by default, not the -lts one or others. As we don't have a way to select the correct kernel version I find more elegant to pull a virtual name which is provided. But like point 6 and 7, I feel you'll claim that is not part of the discussion. So, let's see that later. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
Sébastien, [2016-03-23 22:28:36 +0100] Sébastien Luttringer:
Unexpectedly we got the most feedback from persons who are not dealing currently with the burden of managing kernels and their modules.
It's been more than two weeks since Allan's original message; everybody who wanted to contribute to this discussion has contributed. There's really no need to try and discredit the whole thread with a classical "the silent majority sides with me" fallacy.
4) No one object to having dkms available for all modules; It's even supported by several fellows and this is offering support for AUR and custom kernels at almost no maintenance cost. ==> We must provides dkms build for all modules. Except those covered by 2.
Seriously, man, how do you go from "no one objects to having dkms" to "we must provide dkms"? I mean, we're all trying to have a reasonable discussion here. On this mailing list more than anywhere else. Please refrain from jumping to your own conclusions all the time, it's really annoying, in particular when you have to twist the logic of other people's arguments for that. Allan already pointed this out, but I feel like I must insist:
5) There is no much discussion about which should be the default (a binary flavor or dkms). I would propose a solution which let the user choose which module he want needs by pulling a defined dep like module-$modulename. ==> Applications should pull a generic deps to let users decide which module he wants (flavored or dkms).
Absolutely no. We are a binary distribution. Binary should be the default. Nobody but you argued otherwise.
6) Binary modules should be built from the dkms package.
Wow! Where on earth do you get crazy stuff like that from? It's never been part of this discussion. And what purpose would his additional requirement serve exactly? I really wish you'd argue in good faith instead of simply trying to steer things your way. Cheers. -- Gaetan
So, after all of this, we still only have DKMS modules in [community]. @Sébastien: Is this going to change any time soon? A
On mer., 2016-03-23 at 18:51 -1000, Gaetan Bisson wrote:
bla bla
I really wish you'd argue in good faith instead of simply trying to steer things your way.
I started promoting a way to manage o-o-t modules with only dkms. During the discussion, providing binary modules make consensus. So, I made a concession and moved to a position close to yours, which can be sum as, if we provide binary modules, we should provides them for all kernels. Despite this 180° move, you ask me to not steer things my way. On the other things you wrote, even after a 2 weeks break from Arch, the only discredit I see from the whole discussion is from you and directed to me. -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
[2016-04-13 02:05:13 +0200] Sébastien Luttringer:
I started promoting a way to manage o-o-t modules with only dkms. During the discussion, providing binary modules make consensus. So, I made a concession and moved to a position close to yours, which can be sum as, if we provide binary modules, we should provides them for all kernels.
That's not at all how I understood your last message. I'm sorry you had to take a break from Arch and I apologize if my reply was part of the problem in any way, but I still think what you said goes against most of the views other developers have expressed in this thread. -- Gaetan
On Tue, Mar 15, 2016 at 10:06:22AM +1000, Allan McRae wrote:
On 14/03/16 09:07, Allan McRae wrote:
On 13/03/16 00:52, Sébastien Luttringer wrote:
Please note that as an ideal target, I would have all our kernel modules available via dkms _and_ via prebuilt modules for each kernel flavor we provide. I read on the dev IRC that few modules could only be shipped from sources. Not sure of that btw.
For example, we could, for simplicity says that we provide pre-built modules only for the main kernel and dkms for all others kernels.
What I would like is a team consensus/decision on how we handle kernel oot modules not complains directed on virtualbox only.
I vote for binary modules for all kernels in [core] and dkms versions. Kernels outside of [core] can have binary modules provided at the maintainer's choice.
We are going to need more opinions here to build a consensus...
A
To get this discussion back on the right track I'm going to build the binary modules for virtualbox. Sébastien and myself already discussed what will be done so relatively soon those binary modules will be back. My plan is now to provide the virtualbox modules for -arch -lts and -zen. I think -grsec will be the exception since there are probably protections in there that will block some modules to even build. And when everyone is happy again we probaly should proceed to provide dkms for all out-of-tree modules alongside the binary modules. That would benefit everyone and offer the greatest amount of choice. People using custom kernels can use dkms and have everything working that way and people using one of the kernels available in the repo's can choose if they want dkms or binary. Everyone wins. -- Ike
On Wed, Apr 13, 2016 at 12:14 PM, Ike Devolder <ike.devolder@gmail.com> wrote:
To get this discussion back on the right track I'm going to build the binary modules for virtualbox. Sébastien and myself already discussed what will be done so relatively soon those binary modules will be back.
My plan is now to provide the virtualbox modules for -arch -lts and -zen. I think -grsec will be the exception since there are probably protections in there that will block some modules to even build.
And when everyone is happy again we probaly should proceed to provide dkms for all out-of-tree modules alongside the binary modules. That would benefit everyone and offer the greatest amount of choice. People using custom kernels can use dkms and have everything working that way and people using one of the kernels available in the repo's can choose if they want dkms or binary. Everyone wins.
Please don't add modules for -zen to the repos. They create a maintenance burden I don't want to support. Let -zen users use DKMS; they never had any prebuilt modules anyway.
On Wed, Apr 13, 2016 at 02:05:36PM +0200, Jan Alexander Steffens wrote:
On Wed, Apr 13, 2016 at 12:14 PM, Ike Devolder <ike.devolder@gmail.com> wrote:
To get this discussion back on the right track I'm going to build the binary modules for virtualbox. Sébastien and myself already discussed what will be done so relatively soon those binary modules will be back.
My plan is now to provide the virtualbox modules for -arch -lts and -zen. I think -grsec will be the exception since there are probably protections in there that will block some modules to even build.
And when everyone is happy again we probaly should proceed to provide dkms for all out-of-tree modules alongside the binary modules. That would benefit everyone and offer the greatest amount of choice. People using custom kernels can use dkms and have everything working that way and people using one of the kernels available in the repo's can choose if they want dkms or binary. Everyone wins.
Please don't add modules for -zen to the repos. They create a maintenance burden I don't want to support. Let -zen users use DKMS; they never had any prebuilt modules anyway.
That makes it easier for me. So we stick to binary modules for [core] kernels and the rest does dkms as a middle way. -- Ike
On 2016-04-13 15:44, Ike Devolder wrote:
On Wed, Apr 13, 2016 at 02:05:36PM +0200, Jan Alexander Steffens wrote:
On Wed, Apr 13, 2016 at 12:14 PM, Ike Devolder <ike.devolder@gmail.com> wrote:
To get this discussion back on the right track I'm going to build the binary modules for virtualbox. Sébastien and myself already discussed what will be done so relatively soon those binary modules will be back.
My plan is now to provide the virtualbox modules for -arch -lts and -zen. I think -grsec will be the exception since there are probably protections in there that will block some modules to even build.
And when everyone is happy again we probaly should proceed to provide dkms for all out-of-tree modules alongside the binary modules. That would benefit everyone and offer the greatest amount of choice. People using custom kernels can use dkms and have everything working that way and people using one of the kernels available in the repo's can choose if they want dkms or binary. Everyone wins.
Please don't add modules for -zen to the repos. They create a maintenance burden I don't want to support. Let -zen users use DKMS; they never had any prebuilt modules anyway.
That makes it easier for me. So we stick to binary modules for [core] kernels and the rest does dkms as a middle way.
Let's wait for Andreas opinion on this, but I think that binary modules for -lts are unnecessary. I always used this kernel for servers (where I don't really care about Virtualbox or Nvidia…) and sometimes a fallback if -ARCH is broken. Bartłomiej
On Wed, Apr 13, 2016 at 08:07:34PM +0200, Bartłomiej Piotrowski wrote:
On 2016-04-13 15:44, Ike Devolder wrote:
On Wed, Apr 13, 2016 at 02:05:36PM +0200, Jan Alexander Steffens wrote:
On Wed, Apr 13, 2016 at 12:14 PM, Ike Devolder <ike.devolder@gmail.com> wrote:
To get this discussion back on the right track I'm going to build the binary modules for virtualbox. Sébastien and myself already discussed what will be done so relatively soon those binary modules will be back.
My plan is now to provide the virtualbox modules for -arch -lts and -zen. I think -grsec will be the exception since there are probably protections in there that will block some modules to even build.
And when everyone is happy again we probaly should proceed to provide dkms for all out-of-tree modules alongside the binary modules. That would benefit everyone and offer the greatest amount of choice. People using custom kernels can use dkms and have everything working that way and people using one of the kernels available in the repo's can choose if they want dkms or binary. Everyone wins.
Please don't add modules for -zen to the repos. They create a maintenance burden I don't want to support. Let -zen users use DKMS; they never had any prebuilt modules anyway.
That makes it easier for me. So we stick to binary modules for [core] kernels and the rest does dkms as a middle way.
Let's wait for Andreas opinion on this, but I think that binary modules for -lts are unnecessary. I always used this kernel for servers (where I don't really care about Virtualbox or Nvidia…) and sometimes a fallback if -ARCH is broken.
Bartłomiej
So after 2 or 3 mails we divert further from what I presumed was a sort of consensus. Could we just take this to a vote or something because this sort of impasse will only hurt the users. 1. vote for binary modules - -ARCH - [core] - other? 2. vote for dkms - all out-of-tree modules provide dkms - dkms if the maintainer of the module is willing to do it - no dkms (no longer an option I think) proposal flow for kernel + binary module updates - use separate repo [kernel-update{-testing,-staging}] - announcement to the module maintainers there is an update for a kernel - module maintainers build and push the packages in the respective repo - kernel maintainer can move kernel + modules in the main repo -- Ike
On 14/04/16 19:23, Ike Devolder wrote:
- use separate repo [kernel-update{-testing,-staging}]
Why? We have staging for rebuilds like these.
On Thu, Apr 14, 2016 at 08:06:35PM +1000, Allan McRae wrote:
On 14/04/16 19:23, Ike Devolder wrote:
- use separate repo [kernel-update{-testing,-staging}]
Why? We have staging for rebuilds like these.
So we can have easier updates when a kernel is updated in both core and testing. In that case we would have to land a kernel in core and then update the modules as fast as possible. If this update process has its own repo you can make sure the updates of the kernel and its out-of-tree modules happen on the same time. -- Ike
Am Thu, 14 Apr 2016 13:29:33 +0200 schrieb Ike Devolder <ike.devolder@gmail.com>:
On Thu, Apr 14, 2016 at 08:06:35PM +1000, Allan McRae wrote:
On 14/04/16 19:23, Ike Devolder wrote:
- use separate repo [kernel-update{-testing,-staging}]
Why? We have staging for rebuilds like these.
So we can have easier updates when a kernel is updated in both core and testing.
In that case we would have to land a kernel in core and then update the modules as fast as possible. If this update process has its own repo you can make sure the updates of the kernel and its out-of-tree modules happen on the same time.
There's no need for new repos. I'm for binary modules for our -ARCH main kernel pkg. I see no real need for -lts modules but if there're a few people who find them useful I can handle the kernel rebuilds. No opinion about dkms at all. DKMS could be useful if a foo-dkms pkg is able to detect all local kernels and build required modules without interaction. dkms packages for kernel for which we provide binary modules doesn't provide any more comfort for the user to me. -Andy
On jeu., 2016-04-14 at 18:54 +0200, Andreas Radke wrote:
Am Thu, 14 Apr 2016 13:29:33 +0200 schrieb Ike Devolder <ike.devolder@gmail.com>: I'm for binary modules for our -ARCH main kernel pkg. I see no real need for -lts modules but if there're a few people who find them useful I can handle the kernel rebuilds.
No opinion about dkms at all. DKMS could be useful if a foo-dkms pkg is able to detect all local kernels and build required modules without interaction. dkms packages for kernel for which we provide binary modules doesn't provide any more comfort for the user to me.
So far, everybody wants (or accept we need) a binary package for -arch kernel. So, I pushed a binary package for virtualbox -arch kernel modules. I hope others dkms only packages (ndiswrapper, sysdig) will also provide a binary version for the -arch kernel. This would be a step forward in a common way of providing kernel modules. Regarding binary modules for -lts,-zen,-grsec, I think we should either provides them or not. But not stay in each packager do is own choice. -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
On Mon, Apr 18, 2016 at 2:24 AM, Sébastien Luttringer <seblu@seblu.net> wrote:
So, I pushed a binary package for virtualbox -arch kernel modules.
Thanks! -- Andrea
On 2016-04-18 02:24, Sébastien Luttringer wrote:
On jeu., 2016-04-14 at 18:54 +0200, Andreas Radke wrote:
Am Thu, 14 Apr 2016 13:29:33 +0200 schrieb Ike Devolder <ike.devolder@gmail.com>:
I'm for binary modules for our -ARCH main kernel pkg. I see no real need for -lts modules but if there're a few people who find them useful I can handle the kernel rebuilds.
No opinion about dkms at all. DKMS could be useful if a foo-dkms pkg is able to detect all local kernels and build required modules without interaction. dkms packages for kernel for which we provide binary modules doesn't provide any more comfort for the user to me.
So far, everybody wants (or accept we need) a binary package for -arch kernel. So, I pushed a binary package for virtualbox -arch kernel modules.
I hope others dkms only packages (ndiswrapper, sysdig) will also provide a binary version for the -arch kernel. This would be a step forward in a common way of providing kernel modules.
Regarding binary modules for -lts,-zen,-grsec, I think we should either provides them or not. But not stay in each packager do is own choice.
I'm happy now, thanks.
On Wed, Apr 13, 2016 at 2:05 PM, Jan Alexander Steffens <jan.steffens@gmail.com> wrote:
Please don't add modules for -zen to the repos. They create a maintenance burden I don't want to support. Let -zen users use DKMS; they never had any prebuilt modules anyway.
That said, if the module is interesting enough and GPL-compatible, I'll import it into the ZEN tree (Liquorix users would then get it, too). I've done this with vhba-module and tp_smapi way back when.
On Thu, Apr 14, 2016 at 09:08:50AM +0200, Jan Alexander Steffens wrote:
On Wed, Apr 13, 2016 at 2:05 PM, Jan Alexander Steffens <jan.steffens@gmail.com> wrote:
Please don't add modules for -zen to the repos. They create a maintenance burden I don't want to support. Let -zen users use DKMS; they never had any prebuilt modules anyway.
That said, if the module is interesting enough and GPL-compatible, I'll import it into the ZEN tree (Liquorix users would then get it, too). I've done this with vhba-module and tp_smapi way back when.
Aha so -zen already has some additional modules that are normally out-of-tree. -- Ike
On 2016-03-09 02:44, Sébastien Luttringer wrote:
Debian provides its vbox modules only via dkms and it's not a source distribution (as far I know).
Sure, and as far as I know, we are not Debian. BP
On ven., 2016-03-11 at 07:49 +0100, Bartłomiej Piotrowski wrote:
On 2016-03-09 02:44, Sébastien Luttringer wrote:
Debian provides its vbox modules only via dkms and it's not a source distribution (as far I know).
Sure, and as far as I know, we are not Debian.
No one doubts that. The point was we are not a source distribution because we offer to build o-o-t-m from sources. Cheers, -- Sébastien "Seblu" Luttringer https://seblu.net | Twitter: @seblu42 GPG: 0x2072D77A
Am Wed, 9 Mar 2016 10:19:18 +1000 schrieb Allan McRae <allan@archlinux.org>:
That will fix the use of "optdepends" for things that are not optional (this is not the only package that does this...)
We should have "optdepends" for choice where users should be forced to make a choice like we do now when a "provides" is pulled in. Feature expanding not essential dependencies should better be called "suggested" or similar where no input is required. -Andy
participants (13)
-
Allan McRae
-
Andrea Scarpino
-
Andreas Radke
-
Bartłomiej Piotrowski
-
Daniel Micay
-
Florian Pritz
-
Gaetan Bisson
-
Ike Devolder
-
Jan Alexander Steffens
-
Lukas Jirkovsky
-
Maxime Gauduin
-
Pierre Schmitz
-
Sébastien Luttringer