Re: [arch-dev-public] out of tree modules and alpm-hooks

[Sébastien Luttringer]

On ven., 2016-02-19 at 17:47 +0100, Maxime Gauduin wrote:
> On Fri, Feb 19, 2016 at 4:12 PM, Sébastien Luttringer 
> wrote:
> 
> > I didn't tried them but I don't get how this can works when you
> > install/update
> > a dkms module.
> > 
> I'm aware of that, they were designed that way. That's why with those, and
> your hook triggered by dkms package transactions, every case will be
> covered. I guess it could be possible to handle both within a single hook
> by adding an additional trigger on "usr/src/*" and so on, but I think it's
> probably better to keep them separate.
> 
ok, you want to trigger dkms modules install/uninstall when a kernel is
added/upgraded/removed. Make sense. I completely rewrote the hook and the
script to manage all features you want in version 2.2.0.3+git151023-4.

So, with the last version of the dkms hooking system:
- When a kernel package (with headers) is installed, all DKMS modules are
installed for this kernel (means built and copied into the new kernel modules
tree). Detection is done via alpm-hooks Type=File on
/usr/lib/modules/*/build/include.

- When a kernel package (with headers) is removed, all DKMS modules are removed
for this kernel. Detection is done via alpm-hooks Type=File on
 /usr/lib/modules/*/build/include.

- When a DKMS module package is installed, its kernel modules are installed
(means registered in dkms, built, copied into the modules tree) for each kernel
with headers on the system. Detection is done via alpm-hooks Type=File on
/usr/src/*/dkms.conf

- When a DKMS module package is removed, its modules are removed (means
unregistered from dkms and removed  from the modules tree) of each kernel with
headers on the system. Detection is done via alpm-hooks Type=File on
/usr/src/*/dkms.conf

As dkms do automatically add and build modules when you install them, we don't
need anymore to register/unregister dkms modules in post_install/pre_remove. So
we'll be able to lighten our dkms modules packages. :)

Next steps:
- move dkms to extra, as it is pulled by packages in extra (e.g nvidia-dkms)
- Drop binary modules of virtualbox (and fix the wrong modules path in
/usr/src)

Testing and feedbacks of the dkms package in cty-testing is welcome.

Cheers,

-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: This is a digitally signed message part

Re: [arch-dev-public] out of tree modules and alpm-hooks

[Maxime Gauduin]

On Fri, Feb 19, 2016 at 4:12 PM, Sébastien Luttringer 
wrote:

> On ven., 2016-02-19 at 08:12 +0100, Maxime Gauduin wrote:
> > On Fri, Feb 19, 2016 at 2:27 AM, Sébastien Luttringer 
> > wrote:
> > What about when you remove a dkms package? Would be nice to remove the
> > build modules as well.
> This is done by post install scriplet[1] of each dkms module package (e.g
> it
> calls "dkms remove vhosthost/${1%-*} --all").
>
> Right.


> Name and version of the dkms modules to remove is not easy to guess in a
> global
> hook. Also note that a dkms module can build several kernel modules.
>
> That's also why registering (dkms add) of the modules is done by install
> scriplet.
>
> Only the build/install of registered modules are done by the hook in order
> to
> schedule them properly.
>
> > With these hooks [1] designed for kernel transaction, we will have
> complete
> > support of oot modules in pacman.
> >
> I didn't tried them but I don't get how this can works when you
> install/update
> a dkms module.
>
> I'm aware of that, they were designed that way. That's why with those, and
your hook triggered by dkms package transactions, every case will be
covered. I guess it could be possible to handle both within a single hook
by adding an additional trigger on "usr/src/*" and so on, but I think it's
probably better to keep them separate.


> Your dkms-install hook is triggered by files installation in
> /usr/lib/modules,
> but dkms packages didn't do that at all. They write these files in
> /usr/src/$foo and register the dkms module with dkms add.
>
> Files are copied in /usr/lib/modules when you run "dkms install" (so not
> under
> the watch of alpm), so it make no sense to call dkms install again when
> file
> are here.
>
>
> [1]
> https://projects.archlinux.org/svntogit/packages.git/tree/trunk/nvidia-dkms
> .install?h=packages/nvidia
>
>
> --
> Sébastien "Seblu" Luttringer
> https://seblu.net | Twitter: @seblu42
> GPG: 0x2072D77
>

Re: [arch-dev-public] out of tree modules and alpm-hooks

[Sébastien Luttringer]

On ven., 2016-02-19 at 08:12 +0100, Maxime Gauduin wrote:
> On Fri, Feb 19, 2016 at 2:27 AM, Sébastien Luttringer 
> wrote:
> What about when you remove a dkms package? Would be nice to remove the
> build modules as well.
This is done by post install scriplet[1] of each dkms module package (e.g it
calls "dkms remove vhosthost/${1%-*} --all").

Name and version of the dkms modules to remove is not easy to guess in a global
hook. Also note that a dkms module can build several kernel modules.

That's also why registering (dkms add) of the modules is done by install
scriplet.

Only the build/install of registered modules are done by the hook in order to
schedule them properly.

> With these hooks [1] designed for kernel transaction, we will have complete
> support of oot modules in pacman.
> 
I didn't tried them but I don't get how this can works when you install/update
a dkms module. 

Your dkms-install hook is triggered by files installation in /usr/lib/modules,
but dkms packages didn't do that at all. They write these files in
/usr/src/$foo and register the dkms module with dkms add.

Files are copied in /usr/lib/modules when you run "dkms install" (so not under
the watch of alpm), so it make no sense to call dkms install again when file
are here.


[1] https://projects.archlinux.org/svntogit/packages.git/tree/trunk/nvidia-dkms
.install?h=packages/nvidia


-- 
Sébastien "Seblu" Luttringer
https://seblu.net | Twitter: @seblu42
GPG: 0x2072D77A



signature.asc
Description: This is a digitally signed message part