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 |