[arch-dev-public] DKMS modules for virtualbox

[Sébastien Luttringer]

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>