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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > --------------------------------------------------------------------------------------- > 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. > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
