Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed
On Sun, Nov 06, 2005 at 09:13:35AM -0600, Manoj Srivastava wrote:
> 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.
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
Reply to: