Re: Bug#336732: /lib/modules/*/build symlink should be ignored when checking if kernel is installed
On Sun, Nov 06, 2005 at 11:06:27AM -0600, Manoj Srivastava wrote:
> 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.
It is broken in sarge for something like 9/11th of the official arches, i
believe.
> >> > 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.
the build symlink belongs with the files it symlinks too.
> >> >> 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
Well, if the user breaks its stuff its his own fault, but i guess this can be
solved by adding something to note those are official kernel packages or
something.
> 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.
Nope, there is a turf war going on between you and official developers, that
is different, our plans are wide ranging, and should include all the end-users
needs, so contribute to them instead of resisting for petty little things like
build symlink, and we will make the etch kernel and related packages something
to be proud of, not the mess that debian kernels used to be upto now.
> >> > 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.
By modifying all module packages or entering one additional KSRC line for each
of them, and you where advocating the users, tsk tsk ...
> > 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.
Yeah, the problem is that if we have to take a one day long flamewar about
such a minor issue as the build symlink, just because you are stuborn, it is
not an endearment (?) to work with you to change the public API.
> 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.
So, we will be forced to override that again or drop k-p. How can you be so
hypocritical in sayin in one paragraph that we should work with you and in the
next paragraph say that you reject any argument and will implement your stuff
anyway ? I mean, you provided no real argument for doing it your way, nothing
except the "/lib/modules/<version> should be owned by the kernel-image" which
is not really all that convincing.
Friendly,
Sven Luther
Reply to: