Summary: | Idea: Run kernel checks from all packages? | ||
---|---|---|---|
Product: | Portage Development | Reporter: | David Carlos Manuelda <StormByte> |
Component: | Core - Interface (emerge) | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | enhancement | CC: | anton.bugs, firefly_dude0k, fturco, netbox253, pacho, pms |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=551430 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
David Carlos Manuelda
2014-12-16 03:01:51 UTC
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. |