Created attachment 662461 [details] genkernel.log (gzip) Hello, I set those variables in the configuration file /etc/genkernel.conf: > KERNEL_FILENAME="kernel-%%ARCH%%-%%KV%%.efi" > INITRAMFS_FILENAME="initramfs-%%ARCH%%-%%KV%%.img" I guess they have the same purpose than their respective CLI options --kernel-filename and --initramfs-filename. Once genkernel is done, the files are named as followed in the /var/tmp/genkernel repository: > kernel-x86_64-5.8.11-gentoo-x86_64 > initramfs-x86_64-5.8.11-gentoo-x86_64 > System.map-x86_64-5.8.11-gentoo-x86_64 As result, they don’t have the provided suffix and KERNEL_LOCALVERSION is added anyway. Moreover it looks like (or I didn’t find it) genkernel lacks the support for using the compilation number inside ".version" file at the root of the kernel sources, which I want to use for this rendering: > kernel-x86_64-5.8.11-gentoo_1.efi > initramfs-x86_64-5.8.11-gentoo_1.img > System.map-x86_64-5.8.11-gentoo_1 We can see the configuration file is parsed correctly: > * INITRAMFS_FILENAME set in config file to "initramfs-%%ARCH%%-%%KV%%.img". > * KERNEL_FILENAME set in config file to "kernel-%%ARCH%%-%%KV%%.efi". ../.. > * GK_FILENAME_CONFIG set to 'kernel-config-5.8.11-gentoo' (was: 'kernel-config-%%KV%%') > * GK_FILENAME_KERNEL set to 'kernel-x86_64-5.8.11-gentoo.efi' (was: 'kernel-%%ARCH%%-%%KV%%.efi') > * GK_FILENAME_KERNEL_SYMLINK set to 'kernel' (was: 'kernel') > * GK_FILENAME_SYSTEMMAP set to 'System.map-5.8.11-gentoo' (was: 'System.map-%%KV%%') > * GK_FILENAME_SYSTEMMAP_SYMLINK set to 'System.map' (was: 'System.map') > * GK_FILENAME_INITRAMFS set to 'initramfs-x86_64-5.8.11-gentoo.img' (was: 'initramfs-%%ARCH%%-%%KV%%.img') > * GK_FILENAME_INITRAMFS_SYMLINK set to 'initramfs' (was: 'initramfs') Please see log as attachment.
Names will only be applied to the final file and only when stuff is getting installed.
You’re not serious, never the default configuration file talks about requiring the --install option, and even you in previous bug comment (https://bugs.gentoo.org/744694#c1) said we can "restore the previous naming" with only --kernel-filename and --kernel-localversion options. You even don’t pay attention to the content, you prefer quick reply "RESOLVED INVALID", you even didn’t see I ask about the ".version" content, which you discard because, I repeat, you didn’t read. Except for the ZSTD compression issue, those are bugs I have for years, the quality of the documentation is very poor, with a lot of implies and options blocked by other options, a true spaghetti documentation. Thanks for wasting time.
You filed multiple bugs in short time, always claiming "That's a bug" and I also showed and explained why this isn't a bug. You did not recognize after a few bugs, "Oh, looks like I have other expectations and it's always caused by --no-install" and question the attitude to file bugs for everything you don't understand at first which is kind of rude because you also expect that genkernel maintainer will respond to your bug in timely manner which is a waste of time for us if it turns out that all reported bugs so far are based on the same 'misunderstanding' or different expectation of what should happen when you pass --no-install. .version cannot be considered because after each compilation $KV would change which would break the way most genkernel user expect that genkernel will pick its kernel config. I.e. by default, genkernel reads $KV from sources and will then try to look for matching .config in /etc/kernels because when kernel was build successfully, it will store used .config in that directory by default (--save-config). > those are bugs I have for years, the quality of the documentation is > very poor, with a lot of implies and options blocked by other options, > a true spaghetti documentation. You know how Open Source works, right? So I am looking forward for your contribution to improve documentation.
I never expected someone to answer ASAP, you were the one eager to do it; I don’t mind it takes its time than getting flagged in a few minutes -- the time to just type a mostly default answer -- as "RESOLVE INVALID". I don’t understand how the number of bugs I reported at the same time has something to do about being rude. As I said, those are "bugs" I met for years, I just never took time to report them because it wasn’t blocking to get the resources or I was considering I could test more thoroughly. Except when I met the bug 744691 (about CONFIG_RD_ZSTD). When I met this last one, I thought it was a good opportunity to report them all. Why do you think it’s rude to report multi bugs except of fewer? Do you want only one bug report with everything in it? So you claim you explained why those are not bugs, for me I think you just justified their poor designs, without even considering "is this the only correct workflow?". And how do you want me to call them by default, those "bugs"? Why did the word "bug" trigger you? I even recognized my misunderstanding in the first "bug" report, and had an insight about the source during the time I wrote the "bug" report (just read the title), unlike you claim. The "bug" reports here are also about improving the experience or the documentation if it’s not clear (something might be obvious because you wrote its code, but it might not be for an outsider). In fact, after I read your answer, those are indeed not bugs, they are way worse: faulty design (you could have said in each answer "not a bug, a feature"). You think those issues to be normal: - genkernel modifies the config file without warning the user (no, we don’t read the log by default, and the content on the terminal doesn’t talk about it); - genkernel discards user’s options when they are not compatible between them without warning; - genkernel’s documentation has flaw, example about implied options; the Default configuration doesn’t have the same information, why not simply copy/paste the same content from its man page? - you might be right about this one, but for me, using both a configuration file and CLI options is a bad idea, triggering or discarding options without notice; - the filename issues are non sense, why does the kernel need to be "installed" to be correctly named (which is only copying it in the /boot directory, which is not the place we all want, I didn’t see an option about its destination path)? - why does the kernel need to be installed, again, to trigger the "emerge @module-rebuild" action? I always execute it just after I push modules to the live system (make modules_install) once genkernel is done, it had always worked. This requirement is then false. By the way, this is *gen*kernel, I think we might consider the install part as optional (for example, I don’t use /boot, I use a removable device on FAT32 FS, therefore not necessarily mounted on /boot, and then no sysmlink too, and I want to backup it). Here a non exhaustive list of normal behaviours: - don’t modify input files unless it’s its job, which is not the case (at least not with the --kernel-config option); however, if an kernel option is required for support of software (gpg, lvm, luks, mdadm), then you provide content a message for the user, not behind her back, and stop operation. - don’t discard options, specially when the only answer is in the log, not on stdin; once again, warn the user, stop operation. - and write those warnings in the documentation, we don’t want to "die and retry" like in a video game before getting a grasp on its workflow (and because compilation takes time). - about very extra options like ZSTD compression, why do you consider my fault if a not upstream feature is removed and I had no idea about it? This is a case where a not upstream feature could have a warning in the documentation or the link to it (by the way, it wouldn’t have happened if genkernel doesn’t try to modify the config file). And at last: > You know how Open Source works, right? So I am looking forward for your > contribution to improve documentation. You know it takes plenty of time to start contributing on a project, which can be reject after all. It is advice to first report it, to confirm if it needs modification, than starting solo, wasting plenty of time to understand the code, and finally having a poor result which will be mostly rejected. I also know some project don’t like contributions. If I really wanted to contribute on genkernel, the pragmatic way wouldn’t to work on the documentation, it would be to fix the wrong behaviours, the documentation is the casualty of those lasts. My personal contribution are to remove CONFIG_MICROCODE_OLD_INTERFACE and the default hid-sony module (no, I don’t want to boot my system with a PlayStation controller, but see, I didn’t make a "bug" report about it, because this one truly doesn’t hurt). Coming back to the subject: (In reply to Thomas Deutschmann from comment #3) > .version cannot be considered because after each compilation $KV would > change which would break the way most genkernel user expect that genkernel > will pick its kernel config. I.e. by default, genkernel reads $KV from > sources and will then try to look for matching .config in /etc/kernels > because when kernel was build successfully, it will store used .config in > that directory by default (--save-config). I don’t understand your answer, I don’t understand why it will break anything if it’s a new variable like %%ARCH%% and %%KV%% to use inside the --X-filename options. The goal is to have the ability to have different kernels from a same source, in the case the user will try new configuration and still wants to have the previous (working) kernel and the new (testing) one in her bootloader. Example: kernel-x86_64-5.8.11-gentoo_1.efi working and kernel-x86_64-5.8.11-gentoo_2.efi testing, simply with "kernel-%%ARCH%%-%%KV%%_%%VERSION%%.efi". I never said it should be the default way i.e the way it works for most users, I said “genkernel lacks the support for using the compilation number inside ".version" file at the root of the kernel sources, which I want […]”. If you consider now it’s a bad idea, for some reason, this is then something very different than "the way most genkernel user expect [it]". And by the way, the variable "GK_FILENAME_KERNEL" is correct, then why do you say the kernel needs to be installed to use this variable? Anyway, have a nice day. Next time, don’t consider someone is rude by default for random reasons, you become the rude one.
