Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed
On Sun, 6 Nov 2005 16:59:36 +0100, Sven Luther <sven.luther@wanadoo.fr> said:
> 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.
If you are using kernel-package for all related packages, this
is not broken, and it shall not break in the future.
>> > 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.
I can only catch these errors if kernel-package controls what
packages provide what stuff. If you use kernel-package, but move
things around under its nose, then heck, yes, stuff breaks.
>> >> 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.
How do you know? Any user can create a kernel-image with the
same name as an official image with a different debian revision, and
try and install the official package when it comes out. So, just by
looking at package names, you can not be sure the so called official
package is really official.
kernel-package is trying to help out the end user here, even
if there is a turf war going on between "official" developers and
some end user.
>> > 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.
As I have said on IRC, you can still build third party modules
without kernel-image packages being installed.
> 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.
Err, kernel-package provides a public API. Anything that uses
kernel-package should either use the public API, convince the API or
behaviour to change, or accommodate any changes to the internals of
kernel-package.
The new k-p generated kernel headers packages shall manage
the link in postinst/prerm, and building third party modules in
absense on the linux kernel image is supposed to be done by properly
setting the KSRC, or cd'ing to the headers dir and running
make-kpkg.
manoj
--
"Our vision is to speed up time, eventually eliminating it." -- Alex
Schure
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: