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
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:
> On Tue, 10 Jan 2006 23:53:03 +0100, Sven Luther <sven.luther@wanadoo.fr> said:
>
> > On Tue, Jan 10, 2006 at 04:00:00PM -0600, Manoj Srivastava wrote:
> >> On Tue, 10 Jan 2006 21:05:25 +0100, Sven Luther
>
> >> > Whatever, i think the build directory should just work, and that
> >> > was the agreement we had back then on this. I assumed this was
> >> > indeed the case. Any idea what exactly is going wrong here.
>
> 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.
> > The agreement we had was that the build symlink would always point
> > to a valid directory, which is provided by the linux-headers package
> > for official kernels. I don't care what you do or not for
> > non-official kernels, but on behalf of the kernel team i ask you to
> > not unnecessary break things.
>
> 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.
> 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.
> > So, just always have the build symlink with the headers. The special
> > case of having the build symlink point to the non-packaged sources,
> > well, it could be handled with a diversion or whatever, or just be
> > there. or in some other way.
>
> Why? Is there a technical reason that justifies this special
> casing, and makes official headers conflict with kernel images built
> by the end user? What justifies losing this compatibility?
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.
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.
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.
This is the only sane way of handling this, the header package will have to
match exactly the sources the image package was built with, and furthermore,
the image package should match exactly the build symlink, anything else is
crazy, and for you trying to support some crazy and disruptive usecase, you
are going to cause worlds of hurt to the kernel team, and the stable security
team beyond that, when we start getting strange bug reports caused by the mess
you allowed and encouraged.
So, there you only convinced myself, and i hope the rest of the kernel team i
hope, that anything would be better than allowing this to ever happen, and i
will make sure etch doesn't release which such brokeness.
> > You have a broken solution as far as the official kernels are
> > concerned. I don't care what you do, and we provided code for you to
> > ignore the build symlink when doing that nasty check everyone
> > ignores anyway, but you wouldn't take it.
>
> 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.
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.
> > 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. But then as said, we
where probably lead to believe that you fixed the problem, and where happy
with your solution, provided it always created a working build symlink. If
this is not the case, then we must restart this discussion, which sucks. I
encourage you and jonas to stay polite this time when you run out of argument,
and search excuses to reply to my technical inquiries. And "it has always been
like that" will not be acceptable an argument.
> the build symlink in official kernels headers conflict with every
> other kernel mage package produced? What is the significant
> advantage?
See above, but i will repeat myself. This is a very very wanted feature. First
the official header packages will only conflict with random image packages
*IF* those random image package reuse the official flavour name, which is
a crazy use case we want nothing to have with. I would even go further on
this, and i think it is now clear that we *NEED* this conflict.
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
This should discard that line of argumentation for all, and spare us a world
of hurt in the future. This is also not-negotiable, and etch cannot be
released without either this feature, or linux-2.6 dropping the use of
kernel-package, which i believe is not the right thing to do.
> > Anyway, i don't think this will bring anything, and last time we
> > discussed this, you ended up with abuse and insults against me, and
> > when all thought you had solved the issue, and everyone was happy,
> > you suddenly come again with this brokeness.
>
> The issue is solved. linux-2.6 breaks header packages, but
> that is not my doing.
It is not solved, you need to fix the potential breakage asap, or we will need
to drop kernel-package and provide our own infrastructure. I know Bastian is
just itching to do just that, but i hope it is not necessary as you are right
in insisting that the official kernels should as much as possible be built
exactly like the self-built ones.
Friendly,
Sven Luther
Reply to: