Hi,
I would like to have some opinions about ebuilds that install both
some kernel modules and some userspace binaries. Some examples i
know because i use them are:
- app-misc/lirc
- net-dialup/slmodem
- sys-fs/fuse
- net-fs/shfs
(but i guess there are probably others)
I have to admit that i'm not big on that kind of ebuilds, for
two obvious reasons:
- if one want new instances of the modules for a new target
kernel, he has to rebuild the userspace as well. Not that big
an issue since they are usually small packages, but not that smart
neither.
- if one want the userspace tools but not the modules, it can
be tricky: in above examples, lirc is the only one that allows
that without editing the ebuild, using LIRC_OPTS. And that is not
such an unlikely situation: for instance, Fuse driver is close to
inclusion in kernel (it's already in latest -mm). Also, the
slmodem driver is useless for many people thanks to Alsa. And lirc
or shfs are provided by several kernel patchsets like -cko, etc.
The simplest, but ugliest, solution i can think of would be to add
a "nomodule" USE flag to this ebuilds. A better approach would be
to split them in two different ebuilds. For instance, slmodem
could be split into "slmodem-module" and "slmodemd", with a
"!alsa? ( ~net-dialup/slmodem-module-${PV} )" dependency from
slmodemd, etc. Actually, for the packages i've looked at so
far, spliting ebuilds seems rather easy.
And we could even think of more complicated solutions involving
virtuals (just like for the "Alsa is in 2.6 but not in 2.4" case),
but i think that here it would be bloat.
So what do you think? Could "Do not mix kernelspace and userspace"
become a new ebuild guideline, or not? And would you be interested
if i start working on some splitted ebuilds for the above cited
packages?
Thanks,
--
TGL.
--
[email protected] mailing list
