| 1 |
* Jörg Sonnenberger <joerg.sonnenberger@×××.de> [021124 15:12]: |
| 2 |
|
| 3 |
>> What I do now is having a folder in /usr/src where I keep a copy of all |
| 4 |
>> the kernel module's sources which come with different ebuilds, e.g. |
| 5 |
>> mplayer, svgalib, ... |
| 6 |
|
| 7 |
[...] |
| 8 |
|
| 9 |
>> This way, I can emerge/unmerge those packages without deleting the |
| 10 |
>> module from the kernel tree and at the same time I can have various |
| 11 |
>> kernels with their own modules, which I have to build manually whenever |
| 12 |
>> I compile a new kernel. |
| 13 |
|
| 14 |
[...] |
| 15 |
|
| 16 |
>I like to debian approach of having all modules in /usr/src/modules and a script |
| 17 |
>(make-kpkg) building the kernel with a given configuration, building the modules |
| 18 |
>and packaging it all together. This would be useful not only for packages like |
| 19 |
>mplayer or svgalib which are using "support" modules, but esp. for module only |
| 20 |
>ebuilds like alsa-driver. |
| 21 |
|
| 22 |
Yes, that's approximately what I'm doing now on Gentoo, only that I |
| 23 |
haven't automatized the kernel-modules build yet. |
| 24 |
I hadn't included alsa-driver on the list of ebuilds I cited because in |
| 25 |
that case it is basically a 'kernel-modules' ebuild, i.e. it only |
| 26 |
contains kernel modules, nothing else. Thus, just making Gentoo believe |
| 27 |
the package is not installed (removing the entries in /var/db/pkg) and |
| 28 |
re-emerging it when I compiled a new kernel did the job. |
| 29 |
This approach, on the other hand, was cumbersome with packages on which |
| 30 |
the kernel module is only a small add-on, which accompanies a much bigger |
| 31 |
tarball. |
| 32 |
Take for example mplayer. |
| 33 |
|
| 34 |
Nonetheless, I would give a thumbs up to concentrate and treat in a |
| 35 |
special way all the kernel modules, mplayer's, svgalib's, alsa-driver's |
| 36 |
et all. |
| 37 |
Hence, if you emerge something like svgalib, you would get |
| 38 |
media-libs/svgalib _and_ something like sys-kernel/svgalib, |
| 39 |
sys-kernel/svgalib-kernel, or something similar. |
| 40 |
|
| 41 |
Then we would need a new command, ala make-kpkg, which would rebuild all |
| 42 |
the installed modules for the current kernel. We would use this when we |
| 43 |
need modules for a new kernel. Removal of previously-built modules |
| 44 |
should be an option, not enabled by default. After all, if you decide |
| 45 |
you no longer want to use an old kernel, you'll have to remove all the |
| 46 |
modules for that version yourself, and therefore it wouldn't be too much |
| 47 |
of a hassle to remove extra-modules too - the effort would be exactly |
| 48 |
the same, actually -. |
| 49 |
|
| 50 |
Last, but no least, unmerging media-libs/svgalib would also unmerge |
| 51 |
sys-kernel/svgalib. Here I'm talking about the sources which got |
| 52 |
installed on /usr/src or wherever we decided to put them on, and not |
| 53 |
about the built modules themselves. |
| 54 |
Options to enable/disable some of this behaviors could be OK too. |
| 55 |
|
| 56 |
Oh, if you are wondering about the name collision of both |
| 57 |
media-libs/svgalib and sys-kernel/svgalib, it is my assumption that |
| 58 |
emerge would only return media-libs/svgalib to a search, that is, |
| 59 |
sys-kernel/svgalib would be a transparent addition, which you don't have |
| 60 |
to specify. |
| 61 |
|
| 62 |
Any Gentoo core developer might share his/her (is there any female |
| 63 |
developer within Gentoo?) thoughts on this? |
| 64 |
|
| 65 |
|
| 66 |
-- |
| 67 |
Javier Marcet <jmarcet@×××××.com> |
Archives