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, 11 Jan 2006 08:49:33 +0100, Sven Luther <sven.luther@wanadoo.fr> said:
> CCing the release team, since this has impact on the releasability
> of etch.
> On Tue, Jan 10, 2006 at 09:00:57PM -0600, Manoj Srivastava wrote:
>> The build directory "just works" in the common case, anyway.
> It needs to work in all case, and in particular it needs to work
> with the official kernels. If it don't then k-p is buggy.
Just fix linux-2.6 not to muck with a working package. Or
demonstrate the technical benefit for breaking it in linux-2.6
>> Who's we, kemo sabe? I never agreed to any such thing. I guess
> You, me, everyone ? We may have misunderstood your intentions, it
> seem, but in that case you cannot claim that we agreed to the
> current broken state.
That happens not to be the truth. Show me the mail from me, or
IRC logs, before you go on revising history.
>> the people making the decisions should be doing the work
> As for doing the work, various people of the kernel team provided
> you with patches and you just rejected them because you thought your
> ways was the only right way.
Ah, so this is wounded pride?
> 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.
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.
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
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
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.
2b) The headers are installed first. In this case, before
we install the image, the case is like case 3 below
(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.
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.
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.
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-
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
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.
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
> 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.
> 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?
>> 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.
> 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.
>> > There is no build directory for official kernels, and the only
>> > valid point for the build symlink to point to is the dir provided
>> > by the header package, so there is no build directory, the kernel
>> > headers are installed, then per your own words, the build symlink
>> > should point to this, independently of if the kernel-image is
>> > installed or not. This is what we actually agreed upon, and if
>> > k-p did this, nobody would ever be complaining.
>>
>> WHO agreed upon this? Why was I not in that loop? And why must
> You, me, jonas, everyone that followed that discussion.
That is a lie. Show me an email from me that said I agreed to
shipping the build symlink in the headers. You seem to live in a
fantasy world, with all these assumptions.
> But then as said, we where probably lead to believe that you fixed
> the problem,
Actually, the problem is fixed, linux-2.6 went and screwed up
a working solution.
> 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.
manoj
--
I knew her before she was a virgin. Oscar Levant, on Doris Day
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: