Re: Ncurses?

[Henrik Christian Grove <grove@sslug.dk>]

Morten Bo Johansen <mbj@spamfilter.dk> writes:

> On 07/09, Henrik Christian Grove wrote:
> 
> HCG> Jeg har aldrig set pointen i at bruge make-kpkg, så det er da muligt. 
> 
> Hmm, du burde nu se pointen ;)

Det er da tænkeligt.

>      i) Convenience. I used to compile kernels manually, and it
>         involved a series of steps to be taken in order;
>         kernel-package was written to take all the required steps (it
>         has grown beyond that now, but essentially, that is what it
>         does). This is especially important to novices: make-kpkg
>         takes all the steps required to compile a kernel, and
>         installation of kernels is a snap.

Jeg vil ikke kalde mig selv novice udi kerneoversættelse (den første
kerne jeg selv oversatte var en 2.0.29, midt i juli 1997), og så mange
skridt er der heller ikke i det.

>     ii) It allows you to keep multiple version of kernel images on
>         your machine with no fuss.

Jeg tror ikke jeg forstår det punkt.
Jeg har 12 forskellige oversatte kerner liggende på denne maskine uden
problemer.

>    iii) It has a facility for you to keep multiple flavours of the
>         same kernel version on your machine (you could have a stable
>         2.0.33 version, and a 2.0.33 version patched with the latest
>         drivers, and not worry about contaminating the modules in
>         /lib/modules).

Det har aldrig været et problem for mig, men okay.

>     iv) It knows that some architectures do not have vmlinuz (using
>         vmlinux instead), and others use zImage rather than bzImage,
>         and calls the appropriate target, and takes care of moving the
>         correct file into place.

Det er ikke det store problem for mig. (Måske skulle jeg tage og høre
Kristian om den strømforsyning til en alpha).

>      v) Several other kernel module packages are hooked into
>         kernel-package, so one can seamlessly compile, say, pcmcia
>         modules at the same time as one compiles a kernel, and be
>         assured that the modules so compiled are compatible.

Jeg har kun haft kompatibilitetsproblemer med moduler da jeg prøvede at
køre woodys installationsprogram på en 2.4-kerne.

>     vi) It enables you to use the package management system to keep
>         track of the kernels created. Using make-kpkg creates a .deb
>         file, and dpkg can track it for you. This facilitates the task
>         of other packages that depend on the kernel packages.

Jeg er endnu ikke stødt på en pakke jeg ikke kunne installere på grund
af afhængigheder af en kerne-pakke.

>    vii) It keeps track of the configuration file for each kernel image
>         in /boot, which is part of the image package, and hence the
>         kernel image and the configuration file are always together.

Det er faktisk lidt smart.

>   viii) It allows you to specify a directory with config files, with
>         separate config files for each subarchitecture (even allows
>         for different config files for i386, i486, etc). It is really
>         neat for people who need to compile kernels for a variety of
>         sub architectures.

Hvis man har brug for det, er det da smart. (Men noget mere genrelt er
på vej ind i 2.6-kernerne).

>     ix) It allows to create a package with the headers, or the
>         sources, also as a deb file, and enables the package
>         management system to keep track of those (and there are
>         packages that depend on the package management system being
>         aware of these packages).

Igen er det ikke pakker jeg er stødt på.

>      x) Since the kernel image package is a full fledged Debian
>         package, it comes with maintainer scripts, which take care of
>         details like offering to make a boot disk, manipulating
>         symbolic links in / so that you can make boot loader scripts
>         static (just refer to the symbolic links, rather than the real
>         image files; the names of the symbolic links do not change,
>         but the kernel image file names change with the version).

Det med at lade Lilo-konfigurationen henviser til symlinks, regnede jeg
ligesom ud for seks år siden. (Og så vil jeg hverken have vmlinuz-filen
eller et symlink til den i / - men det synes jeg også at have forstået
at man kan få den til at lade være med).

>     xi) There is support for the multitudinous subarchitectures that
>         have blossomed under the umbrella of the m68k and powerpc
>         architectures.

Hvis der er nogen der sådan en i overskud kan det være jeg ville sætte
pris på det.

>    xii) There is support there for optionally applying patches to the
>         kernel provided as a kernel-patch .deb file, and building a
>         patched kernel auto-magically, and still retain an UN-patched
>         kernel source tree.

Det lyder da smart, men jeg tror ikke jeg har brugt lapper siden
FAT32-support blev en del af standardkernen.

>   xiii) Allows one to compile a kernel for another computer, for
>         example using a fast machine to compile the kernel for
>         installation on a slower machine. This is really nice since
>         the modules are all included in the .deb; and one does not
>         have to deal with modules manually.

Lyder lidt smart.

>    xiv) The postinst looks at a configuration file on the installation
>         machine (as opposed to the machine that the image was compiled
>         on), and allows the local admin to decide on issues of
>         symbolic links, and whether the boot loader stuff must be
>         run, and whether one wants to create a boot floppy or not. 

Så vidt jeg kan se er det altsammen ting der knap nok er et problem hvis
man gør det i hånden.

>     xv) The postinst and the postrm scripts allow the local admin on
>         the installation machine to add a script into runtime hooks;
>         this can allow, amongst other things, grub users to add and
>         remove kernel image stanzas from the grub menu (example
>         scripts to do this are in the package).

Det er vist kun relevant hvis man bruger den samme kerne til flere
maskiner. 

>    xvi) One can append to the kernel version on the command line, or
>         by setting an environment variable. So if your kernel is
>         called kernel-image-2.4.1John.Home; it is unlikely to be
>         overridden by the official 2.4.1 kernel, since they are not the
>         same version.

Jeg har aldrig været ude for at apt-get ville opgradere en kerne, så jeg
forstår ikke problemet.

>            Disadvantages of using make-kpkg
>            ------------- -- ----- ---------
> 
>       i) This is a cookie cutter approach to compiling kernels, and
>          there are people who like being close to the bare metal.

Subscirbe.

>      ii) This is not how it is done in the non-Debian world. This
>          flouts tradition. (It has been pointed out, though, that this
>          is fast becoming Debian tradition)

Det er da dybt ligegyldigt.

>     iii) It forces you to use fakeroot or sudo or super or be root to
>          create a kernel image .deb file (this is not as bad as it
>          used to be before fakeroot).

Hvad skulle problemet være i det?

Alt i alt kan jeg godt se der måske er visse fordele (men ikke så mange
som nævnt), men jeg har svært ved at se den killer-feature der skal få
mig til at begynde at bruge det. Hvis jeg en dag får brug for at styre
flere ens maskiner derimod.

.Henrik

-- 
Linux overalt! - og det kan kun gå for langsomt!