[arch-dev-public] DKMS modules for virtualbox
Sébastien Luttringer
seblu at seblu.net
Sat Mar 12 14:52:36 UTC 2016
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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 811 bytes
Desc: This is a digitally signed message part
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20160312/81872d6f/attachment.asc>
More information about the arch-dev-public
mailing list