Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed
On Sun, 6 Nov 2005 12:39:52 +0000, Martin Michlmayr <tbm@cyrius.com> said:
> * Manoj Srivastava <srivasta@debian.org> [2005-11-05 23:51]:
>> Why should a symlink be ignored? What other stuff would people want
>> to have ignored if we start on a slippery slope like this?
>> nividia-source, vmware, and scads of others would like to dump
>> stuff in /lib/modules, and the book keeping involved in keeping
>> track of stuff in the /lib/modules/ which is OK to ignore would be
>> massive.
>> The presence of that link is a bug, and should be fixed.
> Can you explain why it is a bug? I think upstream puts header files
> in /lib/modules/<foo>/build/ too, so it's not as if this is a Debian
> specific thing. (Correct me if I'm wrong; also CCing -kernel).
No, upstream does not put headers in that location, but a
symbolic link. And the kernel-package does handle th build and source
links in kernel-package itself.
> Given that the warning by kernel-package talks about modules, why
> don't you do a 'find' and look for .o and .ko files?
Err, no. /lib/modules/$version belongs to the image package;
and third parties are not supposed to be putting things in there.
>> kernel-package itself does not create that link, and the entity
>> responsible for that link should know better.
> AFAIK many external build process (for kernel modules) except
> /lib/modules/<foo>/build, so it's hardly a matter about "knowing
> better" on the side of the kernel-headers package.
This is not quite correct. Every other third party modules
that looks for that link looks for /lib/modules/$(uname -r)/build --
in other words, the build link for the cirrent kernel, not some
kernel that is not yet on the machine.
> Unless you get upstream to change, it's quite likely that people
> will have a build symlink in their modules dir and the kernel-build
> message will therefore be useless and even misleading.
> kernel-headers is also different to your other examples
> (e.g. nividia-source) in that it doesn't put _modules_ there. So
> given that this is a well-known exception, I don't see why it would
> be so hard or troublesome to ignore /lib/modules/<foo>/build when
> checking for modules dir. It's like one line of Perl code - and it
> will reduce one false positive.
Can you explain to me why kernel-headers is not putting a
script in /etc/kernel/postinst.d and /etc/kernel/prerm.d to
optionally add and remove the build link?
>> There is a workaround for you, of course, until the bug is fixed in
>> the proper place:
> I'm fairly sure the "proper place" is kernel-package and not
> kernel-headers, as outlined above.
In which case, you have to convince me why the
/etc/kernel/postinst.d is not the right one.
>> ,----[ Manual page kernel-img.conf(5) ] | silent_modules | This
>> option has been put in for the people who are vastly irri- | tated
>> on being warned about preexisting modules directory |
>> /lib/modules/$version That directory may belong to an old or |
>> defunct kernel-image-$version package, in which case problems
> ...
> And even if we continue to disagree, this bug report should be
> reopened to become a wishlist to mention kernel-headers in this
> description.
Feel free to reopen and reassign.
manoj
--
- DDD no longer requires the librx library. Consequently, librx
errors can no more cause DDD to crash. -- DDD
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/%7Esrivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: