On Sun, Nov 06, 2005 at 09:13:35AM -0600, Manoj Srivastava wrote: > On Sun, 6 Nov 2005 12:39:52 +0000, Martin Michlmayr <[EMAIL PROTECTED]> said: > > > * Manoj Srivastava <[EMAIL PROTECTED]> [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.
The build symlink is the ownership of the linux-headers package that contains the pointed to headers, and it should stay so. We had too much trouble with dangling symlinks in the past (probably broken in sarge even), and it is now properly fixed, and should stay fixed, please don't break this now. > > 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. Yeah, you know that you are inconsistent here, you mention the vmware and nvidia packages, whose modules you want to catch, but then you claim no package outside of kernel-image is owning that dir. > >> 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. Any official kernel package whose abi name doesn't change guarantees that the same /lib/modules/$(uname -r) modules will work for any kernel of that version, doing otherwise would be an RC bug, and has delayed even security fixes to be included in kernels in the past, particularly due to d-i. > > 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? Because it is perfectly allowed to build out-of-tree modules without the kernel-image package being installed, it is even part of our upcoming module policy, the above proposal, altough nice, doesn't solve that, and even break it. Please, don't change that, this is not broken, so no reason for you to come and unilateraly break it. > >> 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. See above, but i guess this goes both ways, you have to convince us that the current method is broken, which you have not done, and the only claim i have seen (here and on irc) was that "/lib/modules/<version> should belong to kenrel-image", which you yourself contradict with the case of the nvidia or vmware modules. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
