1 |
On Mon, 29 Apr 2013 02:36:49 +0200 |
2 |
Pavel Nichoski <nichoski@×××××.com> wrote: |
3 |
|
4 |
> This could be done by creating a |
5 |
> separate set of packages, and perhaps adding that set in the |
6 |
> world_sets file, so the packages would get pulled when the user |
7 |
> upgrades @world. |
8 |
|
9 |
Portage allows users to define their own sets, sounds like the most |
10 |
straight forward thing would be generating a user "kernel" set. |
11 |
|
12 |
> The application would be consisted on one command-line tool accepting |
13 |
> various arguments. For example: |
14 |
> -l --list Lists installed kernel versions |
15 |
> -u --upgrade Changes the symlink to the newest kernel version, or if |
16 |
> argument number is given, it sets it to the version under that number |
17 |
> from the list, then generates a .config file using the values of the |
18 |
> previously used kernel version. |
19 |
> -b --build Builds the kernel with the current config |
20 |
> -i --install Moves the kernel image to /boot and includes it in the |
21 |
> bootloader's configuration. |
22 |
> -m --menu Opens the menuconfig |
23 |
> -n --new Creates a new .config file with values based on the system's |
24 |
> profile, hardware info etc. |
25 |
> -d --default Reverts the config file to the default, i.e. as shipped |
26 |
> by the package manager |
27 |
|
28 |
One thing I'm missing here would be a means to verify a .config against |
29 |
installed packages and their recorded CONFIG_CHECKs from |
30 |
linux-info.eclass. |