Many packages have some kernel option checks and give warnings if some of them are not correct (I think in pkg_setup phase) When kernel is updated and/or config is updated, it could be very useful a tool, or an emerge option to run all of these checks from all installed packages with that support. For example: emerge world --<<option_name_here>> Currently, an emulation to do that is to run an emerge -e world, with more jobs than 1, and halting it once it starts compiling, because the first thing it does is run checks for everything. Reproducible: Always
We would need PMS to specify some metadata for this.
What do you check against? * Running kernel? That's kinda wrong, next reboot might not match anyway * Currently selected kernel? That's kinda wrong too, you're still running 'old'
Usually I run checks against current /usr/src/linux/.config, because that is where the kernel is located once rebooted (that is the purpose of the symlink) That way, it is easier to detect config errors, or CONFIG_XXX symbols some packages needs but you changed
We could solve this partially via allowing to run pkg_pretend() of all installed packages.
I realize this is an old bug, but this got me so far: for pkg in $(equery list '*' -F '$category $name $fullversion' | pcre2grep -O '$1/$2/$2-$3.ebuild' -e '([^ ]+) ([^ ]+) (.+)'); do echo "${pkg}:"; ebuild "/usr/portage/${pkg}" clean setup --skip-manifest; done ... I'm just having a tiny bit of trouble locating the ebuild amidst overlays, but it seems to get you 90% of the way there.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=03b441713d299a04c6bdba10e0fbd5ba2340a68d commit 03b441713d299a04c6bdba10e0fbd5ba2340a68d Author: Zac Medico <zmedico@gentoo.org> AuthorDate: 2019-08-10 18:44:11 +0000 Commit: Zac Medico <zmedico@gentoo.org> CommitDate: 2019-08-10 18:51:11 +0000 bin/ebuild: Fix to work with installed package Fix the following AttributeError error: # ebuild /var/db/pkg/sys-apps/portage-2.3.71/portage-2.3.71.ebuild clean pretend clean Traceback (most recent call last): File "/usr/lib/python-exec/python3.6/ebuild", line 318, in <module> type_name=pkg_type) File "/usr/lib64/python3.6/site-packages/_emerge/Package.py", line 72, in __init__ db = self.cpv._db AttributeError: 'str' object has no attribute '_db' Bug: https://bugs.gentoo.org/532674 Fixes: bfe7892202b8 ("_pkg_str: add _db attribute (bug 640318)") Signed-off-by: Zac Medico <zmedico@gentoo.org> bin/ebuild | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)
(In reply to Patrick Lauer from comment #2) > What do you check against? > > * Running kernel? That's kinda wrong, next reboot might not match anyway > > * Currently selected kernel? That's kinda wrong too, you're still running > 'old' Choice may also be left to the administrator of the system. The tool may list installed/configured kernels trees versions, so the adminstrator could choose on which version it want to run the checks.
(In reply to Fab from comment #7) > (In reply to Patrick Lauer from comment #2) > > What do you check against? > > > > * Running kernel? That's kinda wrong, next reboot might not match anyway > > > > * Currently selected kernel? That's kinda wrong too, you're still running > > 'old' > > Choice may also be left to the administrator of the system. > The tool may list installed/configured kernels trees versions, so the > adminstrator could choose on which version it want to run the checks. About this, I just thought, that it can be configured via parameter, i.e. like in genkernel --kernel-config=xxxx, having its default current /usr/src/linux/.config (what's current behavior I think)
*** Bug 705806 has been marked as a duplicate of this bug. ***
(In reply to Patrick Lauer from comment #2) > What do you check against? > > * Running kernel? That's kinda wrong, next reboot might not match anyway > > * Currently selected kernel? That's kinda wrong too, you're still running > 'old' That reasoning is flawed as portage — as of now — has no idea whether rebooting will be relevant to the checks that have just been run when the emerge process ran, so why care? You don't have to change the existing logic, just allow dry-runs at will. Not saying it's easy though...
Found the following script (just 20 lines only) which is a good start: kernel-config-check.py https://gist.github.com/mrueg/cd19a20d2e712f61d2ea
(In reply to Zac Medico from comment #1) > We would need PMS to specify some metadata for this. I think this is one of the cases where we first should have at least a rough idea how to implement it, and only then the spec can follow. Reassigning to dev-portage.
