| 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. |
Archives