Summary: | nvidia-kernel ebuild teeny little patch | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jon Nelson (RETIRED) <jnelson> |
Component: | New packages | Assignee: | Arcady Genkin (RETIRED) <agenkin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | ||
Priority: | High | ||
Version: | 1.1a | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Jon Nelson (RETIRED)
2002-04-28 14:53:37 UTC
I'll take this bug. I actually got rid of the nv_get_kernel_version function altogether (in the version 1.3 of the ebuild), because portage sets $KV variable automatically. Could you test whether portage makes the same kind of mistake? If it does, please open a new bug about this. Thanks. Nope.
Doesn't work.
>>> Completed installing into /var/tmp/portage/nvidia-kernel-1.0.2880/image/
etc/
etc/modules.d/
etc/modules.d/nvidia
lib/
lib/modules/
lib/modules/home/
lib/modules/home/jnelson/
lib/modules/home/jnelson/kernel/
lib/modules/home/jnelson/kernel/2.4.17-r5/
lib/modules/home/jnelson/kernel/2.4.17-r5/kernel/
...
Additionally, why wasn't the ebuild -r value increased? So this becomes a bug in portage now, for it (portage) doesn't set the KV environment variable properly. Please open a new bug report for this, as it is no longer specific to nvidia ebuild. To answer your second question, I chose not to increment the ebuild's revision becase this is an entirely internal fix, i.e. it contains no user-visible changes. There will be no difference on your system after you install this new version of the ebuild, compared to the previous version. Thanks. I disagree. It's not portage's *job* to tell me what kernel I'm compiling a module for. What was wrong with the patch I sent you? It worked for all the test cases I threw at it, although it *could* use more error checking, like "no /usr/src/linux exists" and so on. Jon, it *is* portage's job to tell you that. That task is quite generic and is called for by several more ebuilds (e.g. see alsa-driver and em8300-modules). That was why drobbins added the functionality to Portage in the first place (see bug 599). The function nv_get_kernel_version was written (by me) because KV environment variable was not available at the time. Now KV variable is the ``official'' way of detecting the current kernel version in an ebuild, so the function has to go. Otherwise, there is nothing wrong with the patch that you sent. But understand, that the bug that you discovered also affects at least two more ebuilds. That is why I'm saying, again, that it should be reported as a separate portage bug. This way you can fix it in *one* place, and thus all the packages that compile kernel modules will be fixed. Thanks. I checked the source (Luke), and yep - ebuild.sh does set KV. So I wrote some new code to handle that (for portage). This bug is closed, and thanks for setting me right! |