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:49:33AM +0100, Sven Luther wrote:
> CCing the release team, since this has impact on the releasability of etch.
Oops, forgot to add the CC, ...
> 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
>
>
> --
> To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
> ---------------------------------------------------------------------------------------
> Wanadoo vous informe que cet e-mail a ete controle par l'anti-virus mail.
> Aucun virus connu a ce jour par nos services n'a ete detecte.
>
>
>
Reply to: