Is linux extramodules dir named most appropriately?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Is linux extramodules dir named most appropriately?

arch general mailing list-2
The linux package creates 2 directories; for example:

    /usr/lib/modules/4.14.13-1-ARCH
    /usr/lib/modules/extramodules-4.14-ARCH

Question - Why is the latter not named extramodules-4.14.13-1-ARCH?

Both are owned by the linux-4.14.13 package - and extramodules-4.14-ARCH
will also be owned by the next linux-4.14.14 package and so on.

Perhaps it is something to do with 3rd party packages which install
things in extramodules?


thanks.

gene
Reply | Threaded
Open this post in threaded view
|

Re: Is linux extramodules dir named most appropriately?

arch general mailing list-2
On 01/11/2018 09:09 AM, Genes Lists via arch-general wrote:

> The linux package creates 2 directories; for example:
>
>    /usr/lib/modules/4.14.13-1-ARCH
>    /usr/lib/modules/extramodules-4.14-ARCH
>
> Question - Why is the latter not named extramodules-4.14.13-1-ARCH?
>
> Both are owned by the linux-4.14.13 package - and extramodules-4.14-ARCH
> will also be owned by the next linux-4.14.14 package and so on.
>
> Perhaps it is something to do with 3rd party packages which install
> things in extramodules?
Because the extramodules directory is designated for thirdparty modules
that are believed to be compatible with any kernel patch release of the
same major.minor version. If the module needs to be recompiled with
patch releases, it should be installed to the "main" modules directory.

--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is linux extramodules dir named most appropriately?

arch general mailing list-2
On 1/11/18 9:45 AM, Eli Schwartz via arch-general wrote:
...
>
> Because the extramodules directory is designated for thirdparty modules
> that are believed to be compatible with any kernel patch release of the
> same major.minor version. If the module needs to be recompiled with
> patch releases, it should be installed to the "main" modules directory.
>

Terrific thank you.

Do you know where the directory removal logic is managed?

/usr/share/libalpm/60-linux.hook doesn't seem reveal much to my eye - it
treats 4.14.13-1-ARCH and extramodules-4.14-ARCH indistinguishably. When
linux is updated to 4.15 extramodules gets removed somehow but not with
a minor update.

Thanks.

gene
Reply | Threaded
Open this post in threaded view
|

Re: Is linux extramodules dir named most appropriately?

arch general mailing list-2
On 01/11/2018 11:27 AM, Genes Lists via arch-general wrote:

> On 1/11/18 9:45 AM, Eli Schwartz via arch-general wrote:
> ...
>>
>> Because the extramodules directory is designated for thirdparty modules
>> that are believed to be compatible with any kernel patch release of the
>> same major.minor version. If the module needs to be recompiled with
>> patch releases, it should be installed to the "main" modules directory.
>>
>
> Terrific thank you.
>
> Do you know where the directory removal logic is managed?
>
> /usr/share/libalpm/60-linux.hook doesn't seem reveal much to my eye - it
> treats 4.14.13-1-ARCH and extramodules-4.14-ARCH indistinguishably. When
> linux is updated to 4.15 extramodules gets removed somehow but not with
> a minor update.
*What* directory removal logic???

pacman -Qo /usr/lib/modules/extramodules-4.14-ARCH/

Anyway, see how Red Hat uses "weak modules" in much the same way.


--
Eli Schwartz


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is linux extramodules dir named most appropriately?

arch general mailing list-2
On 1/11/18 12:15 PM, Eli Schwartz via arch-general wrote:
..
> *What* directory removal logic???
>
> pacman -Qo /usr/lib/modules/extramodules-4.14-ARCH/
>
> Anyway, see how Red Hat uses "weak modules" in much the same way.
>
>

When linux is updated to 4.15 the old 4.14.13-1-ARCH modules directory
will be removed and I assumed (possibly incorrectly) that the same is
true for the extramodules-4.14 directory. I guessed, perhaps wrongly,
that both of these were mediated by pacman hooks in
/usr/share/libapm/hooks/xxx.

Otherwise we'd have a slew of unused directories building up in
/usr/lib/modules. In fact this did happen I believe a long time back.

Thanks for explanations.

gene
Reply | Threaded
Open this post in threaded view
|

Re: Is linux extramodules dir named most appropriately?

arch general mailing list-2
Le 11/01/2018 à 18:35, Genes Lists via arch-general a écrit :

> On 1/11/18 12:15 PM, Eli Schwartz via arch-general wrote:
> ..
>> *What* directory removal logic???
>>
>> pacman -Qo /usr/lib/modules/extramodules-4.14-ARCH/
>>
>> Anyway, see how Red Hat uses "weak modules" in much the same way.
>>
>>
>
> When linux is updated to 4.15 the old 4.14.13-1-ARCH modules directory
> will be removed and I assumed (possibly incorrectly) that the same is
> true for the extramodules-4.14 directory. I guessed, perhaps wrongly,
> that both of these were mediated by pacman hooks in
> /usr/share/libapm/hooks/xxx.
>
> Otherwise we'd have a slew of unused directories building up in
> /usr/lib/modules. In fact this did happen I believe a long time back.
That was indeed the case a long time ago for modules built with DKMS,
but now they are hooks for this, in the dkms package that is. But if you
have no DKMS modules, the directory is directly part of the packages you
use (kernel + extra modules) and will be removed by pacman itself as
part of upgrading the corresponding packages, because the new version of
those packages won’t have the dir anymore.

Regards,
Bruno


signature.asc (531 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Is linux extramodules dir named most appropriately?

arch general mailing list-2
On 1/11/18 12:39 PM, Bruno Pagani wrote:
...
>... because the new version of those packages won’t have the dir anymore.
>
> Regards,
> Bruno
>

Ding ... duh of course ...  thank you both for your patience ...