Re: Bug#346281: linux-image-2.6.15-1-686: debconf question about /lib/modules/2.6.15-1-686 even if no kernel is installed
On Wed, Jan 11, 2006 at 08:22:48AM -0600, Manoj Srivastava wrote:
> > I gave some, read the email archive of back then. I think the main
> > technical argument here is that in the official kernel case, the
> > build symlink will *ALWAYS* point to the dir provided by the headers
> > packages, and keeping the symlink in the same package is the more
> > secure way of ensuring that the link is never broken, without
> > involving huge amount of fuss.
>
> What is the use case that requires this? There are three major
> use cases here:
>
> 1) End user build a kernel image, and installs it locally. And
> then wants to build third party modules, like, say,
> vmware. VMware looks for /lib/modules/$(uname -r)/build,
> so, the image package must ship with the build link, in
> order for this to happen. Since the full build dir is
> available, the link always points there, whether or not we
> install header packages later -- but the build link is
> valid.
Ok, this is covered by my proposal in another subthread.
> You can still install a headers package, which does not
> conflict since it has no build link, and if you had removed
> the source dir in between, the header package shall notice
> and install a build symlink correctly. This use case breaks
> in your method.
ok, the header package has to be built from the same source than the image
package, which precludes the header package being an official header package.
Do we agree on this ? This is also covered by my proposal.
> 2) End user, or official kernels, are built on some machine A
> and installed on a target machine B, and there should be no
> conflict between image and headers, and the order should
> not matter
Ok, also supported by my proposal.
> 2a) The kernel image is installed first. In this case, the
> package installs a build symlink, but the postinst
> notices it is a dangling link, and removes it. This is
> the right thing to do, since no headers really exist on
> the FS
Ok, also covered by my proposal.
> When the header package is installed, it checks ti see
> if the build link exists and is valid, which it is not,
> so installs the build link, now $(uname -r) linking is
> valid.
Ok, also covered by my proposal.
> 2b) The headers are installed first. In this case, before
> we install the image, the case is like case 3 below
Ok, i delay my replay to then, i think this is the problem we are having.
> (see discussion there). When the image is installed, it
> installs the build link. The postinst notices that the
> link is dangling, removes it, notices that a header
> installed dir exists, and creates a symlink for build.
Why not have the header then set the symlink, and the image notice it is
already there and leaving it alone ?
> 3) The user installs a header, but not the image. Now, how do
> third party modules build? The trick of looking at the link
> /lib/modules/$(uname -r)/build does not work, since you do
> not have the kernel image corresponding to the headers
> installed, so you can't be running it, so uname -r gives a
> different version.
Well, what would it cost to have the build symlink set right in this case ? My
proposal covers this case also, and it should just work, no need for special
casing for this case, which is not so special anyway. You just get the version
from somewhere instead from the uname output, that is all.
> The answer is that you have to set some env vars. For
> VMWARE, you set KERNEL_SOURCE=/usr/src/linux-headers-foo,
> for debian packaged modules you need to set KSRC to the
> same. In any case, you have to set these variables manually
> to _some_ value, and I do not see why setting it to
> /usr/src/linux-headers-foo is more burdensom than settng it
> to something else.
Why not keep it simple ?
> Also, the Kconfig stuff does not deal with this case, it
> looks for /lib/modules/$(uname -r)/build, which does not
> correspond to the header package we just installed.
>
> I repeat: in this case one has to tell the build system
> where the headers live, and that requires essentially a
> fixed part and the version; I see no difference in hardship
> when the fixed part is /usr/src/linux-headers-
Ok, but it is so easy to keep the header symlink, and you just are searching
lengthy excuses because you don't want to modify the code for checking if
there where modules already there.
> So, from this, comes a set of invariants:
> 1) A user building and installing kernel image packages on a single
> machine must have a working build link
Make this : the link should always be there, in all of the above mentioned
cases and should always be working.
> 2) A user who builds image and header packages and installs them on
> other machines, must have a woking build link no matter which
> order the image and header packages are installed
> 3) /lib/modules/$(uname -r)/build , if it exists, must point to a
> valid directory, be it a dir provided by a headers package, or
> the directory the kernel was built in.
All this is fine.
> 4) If you have installed a header package, but not the image
> package, you should still be able to build third party modules
> using the headers package installed headers
This i disagree with, why not simply set the build symlink correctly in this
case? It is the right thing to do, and is prove against future changes of the
header package name it points to. It allow for a consistent method for all
cases cited, and one which we can guarantee will not change at some future
time.
> > Second, the only drawback from you supporting this is that you don't
> > want to check for the case of /lib/modules/<version> being empty
> > except the build dir, for that module overwrite warning. Is that
> > really worth the cost of all this discussion and lost time ?
> > Especially as we provided you with patches and ideas very early in
> > this discussion, which you just ignored.
>
> Rubbish. I also do not want to ship
> /lib/modules/<version>/build in both headers and image, making them
> conflict.
Why conflicts. You don't seem to know about alternatives, right ? And if you
don't like alternatives, well, simply don't ship the symlink, but always
create it in the header or image postinst, works nicely enough.
> > As for compatibility, sorry, but you are VERY VERY VERY wrong on
> > this. Yes, we, the kernel team, indeed DO *WANT* that if a user
> > compiles his own kernel from random sources using official flavour
> > names, that he cannot use these image packages together with the
> > official header packages or vice-versa.
>
> Why not? Seems like you want to just take these freedoms away
> for no reason apart from you feel yours is the only true way. Where
> is your benefit analysis?
Be serious please. you want the user to screw themselves, and then screw us
all with bogus bug reports which will be a pain to investigate ?
Furthermore, if we don't agree that a header package has to come from the
*SAME* source and configuration file as the image package it corresponds to, i
think you are seriously missing something, and i would very much like to hear
the reasoning which will make this an acceptable use-case, and overweight the
cost it will cause us all.
> >> What is broken if the official build system does not muck up the
> >> perfectly working packages the kernel-package produces?
>
> > You know that in the 6 month or so before you again became actively
> > involved in this again, and we had to sort out our own solution,
> > that the kernel-package produced packages where much less than
> > perfectly working.
>
> So now we discover your solution did not cater to home users,
> and broke use case 1 above, and the new solution caters to
> allusers. The fix is simple as well: stop mucking with a working
> solution.
The solution was *NOT* working, and you were *NOT* there to help us fix it, so
i doubt you can complain about this. I think this is not something from the
last 6 month either, it goes back all the way to when Herbert Xu left.
> > Also, you impose on us non-adequate things, and considering the
> > official kernels as second class citizens compared to your oh so
> > dear folk that self-compile their kernels, is clearly not going to
> > make us happy with kernel-package, and if this and your
> > short-sightness are going to cause the amount of trouble you called
> > for above, then we are better of not using kernel-package.
>
> Bullshit. You just do not seem to have thought about your sue
> cases, and have no idea why your solution should be the one
> implemented, when it adds needless conflicts between packages --
> conflicts that are not encapsulated in the Control file, even -- and
> do not cater to common use cases for user, and require complicated
> work arounds to fix your screw up -- a screw up that adds no benefit
> to anyone.
Yeah, whatever, you have repeteadly claimed on irc things that clearly mean,
even if you don't want to recognize it, that official kernels are the least of
your worries. As long as this stay so, any proposal you make is to be taken
with extreme caution.
> > I thus officially ask you, with RC bug following shortly if you
> > disagree, that you add a conflict:
> > linux-official-<version>-<flavour> to all self built package
> > generated by kernel-package, and we will modify the official image
> > and headers to provide this linux-official-<version>-<flavour>
> > virtual package. Or another solution to this effect
>
> Umm, I refuse to add special casing code, and conflicts
> between official and unofficial packages, until I see some tangible
> benefit of the change.
Well, i have repeteadly now told you the problem and the benefit the kernel
team will have from this, namely not have to deal down the rode with confusing
bug reports, but you fail to recognize this, this has been going as long as
this problem has been discussed, and once you run out of arguments, you
started name-calling, not nice.
Friendly,
Sven Luther
Reply to: