| 1 |
Zac Medico schreef: |
| 2 |
> Holly Bostick wrote: |
| 3 |
> |
| 4 |
>> |
| 5 |
>> This sounds great, but what about the kernel I'm booted into, |
| 6 |
>> against which the module will *not* be compiled, if I have to |
| 7 |
>> reboot before actually configuring/compiling/installing the new |
| 8 |
>> kernel? |
| 9 |
>> |
| 10 |
> |
| 11 |
> You can get pretty close to your desired behavior (merge kernel last) |
| 12 |
> if you simple mask kernel package versions greater than the one that |
| 13 |
> is currently installed. |
| 14 |
> |
| 15 |
> mkdir -p /etc/portage echo ">sys-kernel/gentoo-sources-2.6.14-r2" >> |
| 16 |
> /etc/portage/package.mask |
| 17 |
> |
| 18 |
> That way, portage will not attempt to upgrade it until you tell it |
| 19 |
> that you are ready, by removing the mask. And yeah, if USE=symlink |
| 20 |
> causes problems, don't use it (in my suggested scenario above it |
| 21 |
> might be useful though). |
| 22 |
|
| 23 |
So the ultimate conclusion is that I can either |
| 24 |
|
| 25 |
1) disable the symlink USE flag and manage the redirect manually, which |
| 26 |
would enable me to download any kernel at any time without concern for |
| 27 |
whether a kernel module was upgrading in the same operation; or |
| 28 |
|
| 29 |
2) manually mask kernels, which would enable me to upgrade any kernel |
| 30 |
modules at any time but force me to manually oversee the availability of |
| 31 |
kernel upgrades and manually enable them (and re-disable them following |
| 32 |
said upgrade). |
| 33 |
|
| 34 |
I guess I'll go for option 1, but the long and the short of it is that |
| 35 |
complete automation is unavailable and my only choice is what I prefer |
| 36 |
to manage manually. |
| 37 |
|
| 38 |
OK, then. <sigh> Thanks. |
| 39 |
|
| 40 |
Holly |
| 41 |
-- |
| 42 |
gentoo-user@g.o mailing list |
Archives