1 |
On Sun, 2004-01-04 at 09:30, Paul Varner wrote: |
2 |
> On Sun, 2004-01-04 at 09:17, Marius Mauch wrote: |
3 |
> > On 01/04/04 Drake Wyrm wrote: |
4 |
> > |
5 |
> > > What? No opinions, or everybody thinks I'm too much of an idiot to |
6 |
> > > bother answering? |
7 |
> > |
8 |
> > I think Daniel fixed that already by using the 'don't unmerge' feature |
9 |
> > of CONFIG_PROTECT for /lib/modules. |
10 |
> |
11 |
> It is fixed in the version of portage that is in CVS, but the fix still |
12 |
> hasn't made it to the versions of portage that are marked stable. In |
13 |
> the CVS tree it was placed in version 1.345 of portage.py. The version |
14 |
> that is being distributed is currently 1.341 (See my comments at the end |
15 |
> of bug #1477) |
16 |
> |
17 |
> A manual work around that I have tested is to use env |
18 |
> CONFIG_PROTECT="/lib/modules" when re-emerging packages such as |
19 |
> alsa-driver for a new kernel. However, I don't recommend placing it |
20 |
> into the make.conf as typically you only want to protect the |
21 |
> /lib/modules directory when doing the above. |
22 |
> |
23 |
> I also would like portage-ng to handle kernel modules dependencies in a |
24 |
> more automated fashion. Someone commented that revdep-rebuild was a |
25 |
> hack to get around some of the dependency shortcomings in the current |
26 |
> version of portage. The kernelmod-rebuild script that I recently wrote |
27 |
> is also such a hack. |
28 |
> |
29 |
> I didn't comment on the previous message as I didn't see anything that I |
30 |
> disagreed with from a requirements perspective. |
31 |
> |
32 |
> Regards, |
33 |
> Paul |
34 |
-- |
35 |
Thank you for working out this problem. I, for a second thought I may |
36 |
have instigated a change in portage for the better, but seeing the above |
37 |
metioned bug I see it dates back much farther. Even the fix has been |
38 |
done for several months. |
39 |
|
40 |
Again, thank you for the hard work to improve portage. |
41 |
|
42 |
A side note: Could changes, such as added features, or changed |
43 |
functionality in core projects such as portage be announced in the GWN |
44 |
as they make it to stable. (If it is not already normal) It may be one |
45 |
of the best ways for users to learn about such changes. |
46 |
|
47 |
-- |
48 |
Brian <dol-sen@×××××.net> |
49 |
|
50 |
|
51 |
-- |
52 |
gentoo-portage-dev@g.o mailing list |