Summary: | savedconfig.eclass - config files collide when used in a multi-slotted package (sys-kernel/gentoo-kernel file collision on /etc/portage/savedconfig/sys-kernel/gentoo-kernel) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Michael Moon <triffid.hunter> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dist-kernel |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | emerge --info |
Description
Michael Moon
2021-10-19 11:27:16 UTC
Yeah, I don't think savedconfig really works with slots when you don't include ${PV} in the config file name. Just ran into this again, except first it somehow lost my config completely and I had to re-fetch it from /proc/config.gz, then barfed when I tried to rebuild using my saved config. If I call the file gentoo-kernel-$PV, won't I have to manually rename it for every kernel version? I do the following, maybe it will help you I have per-version configs that are installed as /etc/portage/savedconfig/sys-kernel/gentoo-kernel-5.10.x ( that's literal character x here ) and I simply create a symlink to that file gentoo-kernel-5.10.x or similar will never get overwritten. savedconfig will apply config from file symlink points to. when new kernel arrives, I create new gentoo-kernel-5.14.x for example, and update symlink. You can still loose symlink if you toggle savedconfig flag itself though. an example listing: gentoo-kernel -> gentoo-kernel-5.10.x gentoo-kernel-5.10.x gentoo-kernel-5.8.x gentoo-kernel-5.9.x linux-firmware-20210629 also you probably can use config.d instead of savedconfig https://wiki.gentoo.org/wiki/Project:Distribution_Kernel#Using_.2Fetc.2Fkernel.2Fconfig.d that way you can toggle individual options but leave base config to us. ofc it does not work for everyone, but maybe it'll be enough for you. The config.d approach sounds interesting, I might give that a try. Got any convenient bash magic to tease out the necessary entries from my current config? (In reply to Michael Moon from comment #6) > Got any convenient bash magic to tease out the necessary entries from my > current config? Given the original config file and your modified config file, you could generate an appropriate merge file using the "diffconfig" script from the kernel sources. > scripts/diffconfig -m oldconfig newconfig > merge.config Patch sent for review. https://archives.gentoo.org/gentoo-dev/message/b4c2e48ea7c666282f51802b7ec131fd Thanks for the tip about diffconfig, I'll check that out. If you revert the fix for bug 686348, is there a plan to reimplement that in a way that doesn't cause this issue (818904)? 686348 does seem to raise a valid point. (In reply to Michael Moon from comment #9) > If you revert the fix for bug 686348, is there a plan to reimplement that in > a way that doesn't cause this issue (818904)? 686348 does seem to raise a > valid point. I have no plan to re-implement it. In my view, it's not really a "problem" that needs solving. In some simplification, configuration filenames patterns supported by savedconfig.eclass are: /etc/portage/savedconfig/${CATEGORY}/${PF} /etc/portage/savedconfig/${CATEGORY}/${P} /etc/portage/savedconfig/${CATEGORY}/${PN} After first building of given package, /etc/portage/savedconfig/${CATEGORY}/${PF} would be installed. During next buildings, all patterns would be checked, in order, and first found one is read and later saved. Switching from .../${CATEGORY}/${PF} to another pattern requires explicit renaming by user. Until possible future extension of savedconfig.eclass to support multi-slotted packages, I would argue that it is user's mistake to switch to .../${CATEGORY}/${PN} pattern. I would recommend to not revert that minor feature, which works well in single-slotted packages, and to think about possibly improving savedconfig.eclass. Some possibility is to extend filenames of newly saved configuration files with a separator character and e.g. build date. Example: /etc/portage/savedconfig/${CATEGORY}/${PN}@$(date "+%Y%m%d%H%M%S") restore_config() function would use file with highest number after "@". The issue with using anything other than $PN is that the saved config doesn't get applied to new versions of the package - I tried renaming /etc/portage/savedconfig/gentoo-kernel to …-5.14.15 but the config didn't get used for 5.14.16 which left me with an unbootable system. I also tried config.d but it seems like a ton of options that I put there were subsequently overwritten by I assume the ebuild or eclass config construction process (In reply to Arfrever Frehtes Taifersar Arahesis from comment #11) With my patch to revert your change, I see savedconfig working like this: 1. User installs package intially. 2. User renames savedconfig/.../${PF} to ${PN}. 3. Initial builds of new slots use ${PN} when restoring the config, and save the resulting config in ${PF}. 4. Rebuilds use ${PF}, unless the user takes action to remove that file between rebuilds. Behavior 3 will result in several copies of a similar config file existing. Not a big deal. Behavior 4 is possibly undesired but I think this will suffice until someone actually submits a better patch that does not introduce file collisions. What happens if the package doesn't own the savedconfig, ie it's copied during postinst or something? (In reply to Michael Moon from comment #14) > What happens if the package doesn't own the savedconfig, ie it's copied > during postinst or something? Two problems: 1. That would bypass CONFIG_PROTECT. 2. It would leave behind orphaned files when the package is unmerged. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=eb71dfec11e09ae40ae90f27305948097b6591a2 commit eb71dfec11e09ae40ae90f27305948097b6591a2 Author: Mike Gilbert <floppym@gentoo.org> AuthorDate: 2021-10-31 19:16:06 +0000 Commit: Mike Gilbert <floppym@gentoo.org> CommitDate: 2021-11-05 19:17:13 +0000 savedconfig.eclass: do not re-use config file scheme This causes file collisions when save_config is used in a multi-slotted package and the config file is named ${PN}. Reverts: a0c35ad8ee8f8f89ba6044dd5b44e9479c6a1775 Bug: https://bugs.gentoo.org/686348 Closes: https://bugs.gentoo.org/818904 Signed-off-by: Mike Gilbert <floppym@gentoo.org> eclass/savedconfig.eclass | 15 +-------------- 1 file changed, 1 insertion(+), 14 deletions(-) |