Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 2431 - Portage kernel version autodetection inefficiency
Summary: Portage kernel version autodetection inefficiency
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Unclassified (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Daniel Robbins (RETIRED)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-05-04 02:29 UTC by Arcady Genkin (RETIRED)
Modified: 2011-10-30 22:20 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Arcady Genkin (RETIRED) gentoo-dev 2002-05-04 02:29:38 UTC
Portage sets KV environment variable for every portage build (see ebuild.sh). 
However, this is a bit expensive, since there is an external awk/Python script
involved, as well as the first few lines of /usr/src/linux/Makefile being parsed
to extract the information.  While I think that this is definitely the right way
to determine the kernel version, as opposed to seeing where the symlink points
(thanks to Jon Nelson), it is inefficient to set KV for building packages that
don't need to know installed kernel version.

I propose that instead of setting KV universally we provide a stand alone script
to do the same job, which can be invoked as needed.  This was the original idea
when KV was introduced as response to bug 599, but for some reason it
materialized as an environment variable.

Since implementing this is trivial, I'm attaching no patch.
Comment 1 Arcady Genkin (RETIRED) gentoo-dev 2002-05-10 19:22:49 UTC
Hiya drobbins.  Could you please provide one line's worth of reasoning for
closing this bug?
Comment 2 Daniel Robbins (RETIRED) gentoo-dev 2002-05-10 21:41:09 UTC
jnelson coded a "lighter than before" solution that doesn't rely on starting
another process.  It still uses KV, but it's light enough for me.  Also, this is
definitely not a performance bottleneck for the Portage code so it makes no
sense to optimize here.