Gentoo Archives: gentoo-dev

From: Thomas de Grenier de Latour <degrenier@×××××××××××.fr>
To: gentoo-dev@g.o
Subject: Re: [gentoo-dev] [RFC] A proposal regarding packages that provide kernel modules
Date: Tue, 16 Sep 2003 15:12:09
Message-Id: 1063725127.3f672847a9d86@webmail.easyconnect.fr
In Reply to: [gentoo-dev] [RFC] A proposal regarding packages that provide kernel modules by Georgi Georgiev
1 En réponse à Georgi Georgiev <chutz@×××.net>:
2
3 > Expecting your comments and I hope we reach some kind of
4 solution.
5
6 I was also often upset by portage making some cleanup in my
7 /lib/modules directory, so I've wrote sometime ago a small
8 patch which allow to protect some files from cleaning if
9 they are in one of the paths defined in a make.conf var:
10 CLEAN_PROTECT. I've submit it as bug #24990. The version on
11 bugzilla is not really good though, because protected files
12 will be completly forgotten by portage after the package
13 unmerge/clean.
14 I've got another version which does the following:
15 - protection is done against "clean" (when
16
17
18 --
19 TGL.
20
21 En réponse à Chris Gianelloni <wolf31o2@g.o>:
22
23 > I like it.
24 >
25 > As it stands right now, when I use a new kernel, I have to
26 remerge
27 > nvidia-kernel, lm-sensors, cisco-vpnclient-3des,
28 pcmcia-cs, and re-run
29 > /opt/vmware/bin/vmware-config.pl to rebuild all the
30 modules. This can
31 > be a serious pain and something I forget to do quite
32 often, especially
33 > when testing out kernels. My current solution is to move
34 all of the
35 > modules that are built into a new location under
36 /lib/modules/<ver> to
37 > keep them from being automatically removed with the next
38 merge.
39 >
40
41 I also think that something really need to be done about
42 drivers in
43 portage. The solution proposed on bug #3120 (multiple slots
44 for a same
45 pkg-ver, and slotting drivers to $KV as some are already) is
46 elegant,
47 but it seems hard to implement. It may be a too deep change
48 for a
49 very specific issue. (I've not found any other example where
50 multiple
51 slots may be usefull, but if you have some, please share).
52
53 Solution proposed by Georgi may be easier, and the "modules"
54 counterpart to "world" would be nice. I also like it.
55
56 That said, I've started myself to implement yet another,
57 easier, a
58 solution to this problem, and it's almost already finished.
59 It's not
60 very sofisticated though:
61
62 - user can define a list of path to protect in his make.conf.
63 CLEAN_PROTECT="/lib/modules" is a good value in our case.
64
65 - when a package is "safely unmerged" (what happens if you
66 install
67 foo/bar-1.0 twice), then files within CLEAN_PROTECT path
68 and that
69 should have been removed are instead protected and added to
70 the
71 new CONTENTS file of foo/bar-1.0.
72
73 - when you upgrade foo/bar-1.0 to foo/bar-1.1, and have
74 "autoclean"
75 feature, or do a manual "emerge -c", the same happens:
76 protected
77 files from 1.0 are added to the CONTENTS of 1.1, instead of
78 being
79 deleted. (if the package is in several version in several
80 slots,
81 then the protecting pkg will always be the one in the same
82 slot,
83 but in case of "prune". The logic is exactly the one of the
84 clean or
85 prune in emerge.)
86
87 - when you really want to uninstall foo/bar, "emerge -C"
88 won't take
89 the protection into account. Because the CONTENTS file is
90 up to date
91 with all previous versions of the files, it will remove
92 then all.
93 Hence the day you switch from nvidia to ati, "emerge -C
94 nvidia-kernel"
95 will do the cleanup for all kernels modules directories.
96
97 So far it seems to work for me. I have files from several
98 modules dirs
99 in my alsa-driver and nvidia-kernel CONTENTS files. But
100 there are a few
101 limitations: I've not implemented protection for objects
102 other than
103 files (dirs, symlinks, fifo). Mainly because I don't need it
104 though.
105 That's why I've not submitted it so far. (In fact, the first
106 version
107 of this patch is submitted as bug #24990, but it's really
108 not good
109 because it makes portage completly forget the existence of
110 files that
111 have been protected.)
112
113 In short, this approach is okay for keeping modules
114 installed in
115 several kernels without manual backup (well, at least I use
116 it), but is
117 not specific to modules, so for this precise use it is less
118 powerful
119 that what Georgi suggested (no "modules" world-like file and no
120 "install modules only" ebuild functions). But it may also be
121 useful for
122 a few other task (for instance keeping all icons/backgrounds
123 that come
124 with a WM theme package, accross several versions).
125
126 Any comments on the above ideas are welcome. I will also
127 submit an
128 up-to-date patch in bug #24990, but not before the next few
129 hours
130 (I'm not at home right now).
131
132 --
133 TGL.
134
135 --
136 gentoo-dev@g.o mailing list

Replies

Subject Author
Re: [gentoo-dev] [RFC] A proposal regarding packages that provide kernel modules Thomas de Grenier de Latour <degrenier@×××××××××××.fr>