https://wiki.gentoo.org/wiki/Project:Distribution_Kernel You are pursuing the right goal with a wrong design. The right goal is: 1) place the files "kernel", "initramfs" and modules under package manager control 2) providing a default configuration(s?) the third point is bit unclear to me But you are doing it in a wrong way. Gentoo have already a way to deploy binary packages, it's PORTAGE_BINHOST variable. That's why there should be no *-bin packages for the same task. *bin packages have another purpose - they mark foreign parts of code, which have no sources. What one should do instead is provide .eclass to support genkernel script, and provide set of ebuilds which use that eclass to automate the build process, and capture the list of files to install. i.e. the ebuilds should contain different configs, and have names like buildprocess/gentoo-kernel buildprocess/gentoo-kernel-for-xen buildprocess/gentoo-kernel-for-qemu and so on.
(In reply to Einstok Fair from comment #0) > But you are doing it in a wrong way. Gentoo have already a way to deploy > binary packages, it's PORTAGE_BINHOST variable. That's why there should be > no *-bin packages for the same task. 1. This is not 'Gentoo' but 'Portage' way. It's not portable. 2. Gentoo binary packages are fragile and are going to cause people to keep rebuilding the kernel unnecessarily all the time. 3. There's no technical reason not to provide alternatives, especially when 'your way' has known limitations. > *bin packages have another purpose - they mark foreign parts of code, which > have no sources. Please prove this with a reference to the relevant policy. > What one should do instead is provide .eclass to support genkernel script, > and provide set of ebuilds which use that eclass to automate the build > process, and capture the list of files to install. ...which is already done, except that is uses plain make + dracut because genkernel has proven not flexible enough so far. The question is: why do you file such insulting bugs without even checking?
I tried to install sys-kernel/gentoo-kernel from .tbz2 file with commands # emaint binhost --fix (to update Packages file for uploaded PKGDIR contents) # emerge -a --usepkgonly =gentoo-kernel-5.4.52 (it had USE="symlink" inside XPAC, but that didn't worked) the result was: # ls -1 /usr/src linux linux-5.4.52 linux-5.4.52-gentoo # readlink /usr/src/linux linux-5.4.52-gentoo i.e. that package neither used default sources, nor changed symlink. I (mistakenly) expected that sys-kernel/gentoo-kernel should have sys-kernel/gentoo-sources as it dependency. After all it said * Installing the kernel via installkernel ... [ ok ] * /usr/src/linux points at another kernel, leaving it as-is. * Please use 'eselect kernel' to update it when desired. I don't understood what "it" means. kernel was not installed? or kernel was installed, and just symlink was not changed? # ls -1 /boot | grep 5.4.52 System.map-5.4.52 config-5.4.52 initramfs-5.4.52.img vmlinuz-5.4.52 But symlinks /boot/kernel /boot/initramfs was not changed (not only /usr/src/linux) The ebuild file sys-kernel/gentoo-kernel-bin use files with .xpac-extesions in SRC_URI. But how they was built? Are they the result of qtbz2 -s gentoo-kernel-5.4.52.tbz2 command, or they are full .tbz2 files, but renamed? Also, initrd file was built at the target machine by dracut for the second time, the file created on build-server was not used. If I want to embed wireguard modules (together with systemd-netwrokd configs for them) into initramfs on build server, what should i do?
