Re: [gentoo-dev] [RFC] A proposal regarding packages that provide kernel modules

[Thomas de Grenier de Latour]

En réponse à Chris Gianelloni <wolf31o2@g.o>:

> I like it.
>
> As it stands right now, when I use a new kernel, I have to
remerge
> nvidia-kernel, lm-sensors, cisco-vpnclient-3des,
pcmcia-cs, and re-run
> /opt/vmware/bin/vmware-config.pl to rebuild all the
modules.  This can
> be a serious pain and something I forget to do quite
often, especially
> when testing out kernels.  My current solution is to move
all of the
> modules that are built into a new location under
/lib/modules/<ver> to
> keep them from being automatically removed with the next
merge.
>

I also think that something really need to be done about
drivers in 
portage. The solution proposed on bug #3120 (multiple slots
for a same 
pkg-ver, and slotting drivers to $KV as some are already) is
elegant, 
but it seems hard to implement. It may be a too deep change
for a 
very specific issue. (I've not found any other example where
multiple
slots may be usefull, but if you have some, please share).

Solution proposed by Georgi may be easier, and the "modules" 
counterpart to "world" would be nice. I also like it.

That said, I've started myself to implement yet another,
easier, a 
solution to this problem, and it's almost already finished.
It's not
very sofisticated though:
 
 - user can define a list of path to protect in his make.conf.
 CLEAN_PROTECT="/lib/modules" is a good value in our case.
 
 - when a package is "safely unmerged" (what happens if you
install
 foo/bar-1.0 twice), then files within CLEAN_PROTECT path
and that 
 should have been removed are instead protected and added to
the 
 new CONTENTS file of foo/bar-1.0.
 
 - when you upgrade foo/bar-1.0 to foo/bar-1.1, and have
"autoclean"
 feature, or do a manual "emerge -c", the same happens:
protected 
 files from 1.0 are added to the CONTENTS of 1.1, instead of
being 
 deleted. (if the package is in several version in several
slots, 
 then the protecting pkg will always be the one in the same
slot, 
 but in case of "prune". The logic is exactly the one of the
clean or
 prune in emerge.)

 - when you really want to uninstall foo/bar, "emerge -C"
won't take 
 the protection into account. Because the CONTENTS file is
up to date
 with all previous versions of the files, it will remove
then all. 
 Hence the day you switch from nvidia to ati, "emerge -C
nvidia-kernel"
 will do the cleanup for all kernels modules directories.
 
So far it seems to work for me. I have files from several
modules dirs
in my alsa-driver and nvidia-kernel CONTENTS files. But
there are a few
limitations: I've not implemented protection for objects
other than 
files (dirs, symlinks, fifo). Mainly because I don't need it
though. 
That's why I've not submitted it so far. (In fact, the first
version 
of this patch is submitted as bug #24990, but it's really
not good 
because it makes portage completly forget the existence of
files that 
have been protected.)

In short, this approach is okay for keeping modules
installed in 
several kernels without manual backup (well, at least I use
it), but is
not specific to modules, so for this precise use it is less
powerful 
that what Georgi suggested (no "modules" world-like file and no 
"install modules only" ebuild functions). But it may also be
useful for
a few other task (for instance keeping all icons/backgrounds
that come 
with a WM theme package, accross several versions).

Any comments on the above ideas are welcome. I will also
submit an 
up-to-date patch in bug #24990, but not before the next few
hours 
(I'm not at home right now).

-- 
TGL.

--
gentoo-dev@g.o mailing list