Morten Bo Johansen <[EMAIL PROTECTED]> 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!
