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 [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
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:52:18 +0100, Sven Luther [EMAIL PROTECTED] said: 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. BTW, what about the image and headers both providing the build symlink, except for official images which will not, and using the alternatives mechanism, with the header symlink having the bigger priority ? This way everyone is happy, it just work, and the user can even override things. Err, this is additional complexity, and for what benefit? I still have seen nothing that explains what we gain from the headers containing the link. What is the use case? How is the link used? We still need to provide stong conflict between official packages and compiled from random source reusing the same name. And I think this is a bug. We should be minimizing needless conflicts between packages, not adding them -- especially if there is no tangible benefit. manoj -- I have been poor and I have been rich. Rich is better. Sophie Tucker Manoj Srivastava [EMAIL PROTECTED]http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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:52:18 +0100, Sven Luther [EMAIL PROTECTED] said: 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. BTW, what about the image and headers both providing the build symlink, except for official images which will not, and using the alternatives mechanism, with the header symlink having the bigger priority ? This way everyone is happy, it just work, and the user can even override things. Err, this is additional complexity, and for what benefit? I still have seen nothing that explains what we gain from the headers containing the link. What is the use case? How is the link used? We still need to provide stong conflict between official packages and compiled from random source reusing the same name. And I think this is a bug. We should be minimizing needless conflicts between packages, not adding them -- especially if there is no tangible benefit. manoj -- A company is known by the men it keeps. Manoj Srivastava [EMAIL PROTECTED]http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 [EMAIL PROTECTED] 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
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
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
reassign 346281 kernel-package thanks On Sun, Jan 08, 2006 at 06:00:06PM -0600, Manoj Srivastava wrote: Why is the kernel headers package still installing a build link? We decided that this is correct. The Wiki article at http://wiki.debian.org/KernelModulesPackaging states that we shall use /usr/src/linux-headers-foo as KSRC, and when you install a kernel headers _and a kernel image (in any order), the build link shall be correctly set. This applies to module packages, not handbuilt sources. Bastian -- Women are more easily and more deeply terrified ... generating more sheer horror than the male of the species. -- Spock, Wolf in the Fold, stardate 3615.4 signature.asc Description: Digital signature
Processed: 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
Processing commands for [EMAIL PROTECTED]: reassign 346281 kernel-package 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 Bug reassigned from package `linux-image-2.6.15-1-686' to `kernel-package'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
reassign 346281 linux-2.6 thanks Hi, If you have decided that putting the build link in headers is correct, then you get to fix this. The kernel-package tool does it dofferently, and while you are not required to follow what k-p does, any non-standard and unsupported changes you make to the way k-p works is your responsibility to fix. kernel-package has these requirements for the build and source links: 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, $(uname -r) indirection does not work, so you have to manually set an env variable to point to the directory where the headers live, and since you must set KSRC by hand, set it to /usr/src/linux-headers-foo as you need. This does not add an additional burdenm, it is not as if KSRC did not have to be set by the user manually. manoj -- Happiness is just an illusion, filled with sadness and confusion. Manoj Srivastava [EMAIL PROTECTED] http://www.debian.org/%7Esrivasta/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 Tue, Jan 10, 2006 at 10:33:25AM -0600, Manoj Srivastava wrote: reassign 346281 linux-2.6 thanks Hi, If you have decided that putting the build link in headers is correct, then you get to fix this. The kernel-package tool does it dofferently, and while you are not required to follow what k-p does, any non-standard and unsupported changes you make to the way k-p works is your responsibility to fix. 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. kernel-package has these requirements for the build and source links: 1) A user building and installing kernel image packages on a single machine must have a working build link As far as official kernels are concerned, we don't care about this case, and since the flavour will be different (a user building a flavour of the same name as the official kernels, and having the official kernels installed, has only himself to blame if things break :), whatever happens to self-compiled kernels is fully orthogonal to what is done for official kernels. 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 identic here. Notice though that the header package always providing the symlink is the easiest and sanest way to have your criteria fullfilled. 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. Ok, well, this is not so nice. For official kernels, there is no such thing as the directory the kernel was built in, so the build symlink *MUST* point to the dir provided by the header package. 4) If you have installed a header package, but not the image package, $(uname -r) indirection does not work, so you have to manually set an env variable to point to the directory where the headers live, and since you must set KSRC by hand, set it to /usr/src/linux-headers-foo as you need. This does not add an additional burdenm, it is not as if KSRC did not have to be set by the user manually. Well, maybe, but it doesn't really change all that much all the same, and since both 2) and 3) favour havint the linux-headers provide the build symlink, i think it is obvious what should be done :) Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 Tue, 10 Jan 2006 21:05:25 +0100, Sven Luther [EMAIL PROTECTED] said: On Tue, Jan 10, 2006 at 10:33:25AM -0600, Manoj Srivastava wrote: reassign 346281 linux-2.6 thanks Hi, If you have decided that putting the build link in headers is correct, then you get to fix this. The kernel-package tool does it dofferently, and while you are not required to follow what k-p does, any non-standard and unsupported changes you make to the way k-p works is your responsibility to fix. 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. Define just work. And the agreement I recall was codified on http://wiki.debian.org/KernelModulesPackaging kernel-package has these requirements for the build and source links: 1) A user building and installing kernel image packages on a single machine must have a working build link As far as official kernels are concerned, we don't care about this case, and since the flavour will be different (a user building a flavour of the same name as the official kernels, and having the official kernels installed, has only himself to blame if things break :), whatever happens to self-compiled kernels is fully orthogonal to what is done for official kernels. As the person who has to write and modify the special case code, I beg to differ. I need some solid technical rationale and a clear cost benefit analysis before any additional special case code for official images would be added, and I am in the process of eliminating the special case code we already have. So, soon, there shall just be a vanilla k-p, the same for anyone, and if there is any benefit for doing things one way, these benefits should accrue to all users. 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 identic here. Notice though that the header package always providing the symlink is the easiest and sanest way to have your criteria fullfilled. Easy is for the person writing the code to decide. I have a working solution, and I think changing it is harder, since it involves new code. 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. Ok, well, this is not so nice. For official kernels, there is no such thing as the directory the kernel was built in, so the build symlink *MUST* point to the dir provided by the header package. I do not think you understand what I said. If there is a build directory, the build links points to that. If there is no build directory, but thre is a kernel headers provided directory, then the build link points to that. Or else, there is no build symlink. 4) If you have installed a header package, but not the image package, $(uname -r) indirection does not work, so you have to manually set an env variable to point to the directory where the headers live, and since you must set KSRC by hand, set it to /usr/src/linux-headers-foo as you need. This does not add an additional burdenm, it is not as if KSRC did not have to be set by the user manually. Well, maybe, but it doesn't really change all that much all the same, and since both 2) and 3) favour havint the linux-headers provide the build symlink, i think it is obvious what should be done :) 2 does not favour it, and neither does 3, which you have failed to understand. Look at the code to see what is happening. manoj -- People are going to scream bloody murder about that. Seen on linux-kernel Manoj Srivastava [EMAIL PROTECTED]http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 Tue, Jan 10, 2006 at 04:00:00PM -0600, Manoj Srivastava wrote: On Tue, 10 Jan 2006 21:05:25 +0100, Sven Luther [EMAIL PROTECTED] said: On Tue, Jan 10, 2006 at 10:33:25AM -0600, Manoj Srivastava wrote: reassign 346281 linux-2.6 thanks Hi, If you have decided that putting the build link in headers is correct, then you get to fix this. The kernel-package tool does it dofferently, and while you are not required to follow what k-p does, any non-standard and unsupported changes you make to the way k-p works is your responsibility to fix. 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. Define just work. And the agreement I recall was codified on http://wiki.debian.org/KernelModulesPackaging Jonas and you wrote that one unilaterally despite my protests, i don't recognize that document. And since jonas seems to be kind-of MIA since a couple of weeks, this leaves only you. 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. kernel-package has these requirements for the build and source links: 1) A user building and installing kernel image packages on a single machine must have a working build link As far as official kernels are concerned, we don't care about this case, and since the flavour will be different (a user building a flavour of the same name as the official kernels, and having the official kernels installed, has only himself to blame if things break :), whatever happens to self-compiled kernels is fully orthogonal to what is done for official kernels. As the person who has to write and modify the special case code, I beg to differ. I need some solid technical rationale and a clear cost benefit analysis before any additional special case code for official images would be added, and I am in the process of eliminating the special case code we already have. 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. So, soon, there shall just be a vanilla k-p, the same for anyone, and if there is any benefit for doing things one way, these benefits should accrue to all users. Sure, you are just too stuborn to actually see our needs. You still consider the official kernel packages as second class citizens. 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 identic here. Notice though that the header package always providing the symlink is the easiest and sanest way to have your criteria fullfilled. Easy is for the person writing the code to decide. I have a working solution, and I think changing it is harder, since it involves new code. 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. 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. Ok, well, this is not so nice. For official kernels, there is no such thing as the directory the kernel was built in, so the build symlink *MUST* point to the dir provided by the header package. I do not think you understand what I said. Sure. you take lot of hoops and special cases for a situation which will *NEVER* arise with official kernels. Just have the header package carry the symlink for official kernels, and be done with it. If there is a build directory, the build links points to that. If there is no build directory, but thre is a kernel headers provided directory, then the build link points to that. Or else, there is no build symlink. 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. 4) If you have installed a header package, but not the image package, $(uname -r) indirection does not work, so you have to manually set an env
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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Jan 2006 23:53:03 +0100 Sven Luther [EMAIL PROTECTED] wrote: On Tue, Jan 10, 2006 at 04:00:00PM -0600, Manoj Srivastava wrote: On Tue, 10 Jan 2006 21:05:25 +0100, Sven Luther [EMAIL PROTECTED] said: On Tue, Jan 10, 2006 at 10:33:25AM -0600, Manoj Srivastava wrote: reassign 346281 linux-2.6 thanks Hi, If you have decided that putting the build link in headers is correct, then you get to fix this. The kernel-package tool does it dofferently, and while you are not required to follow what k-p does, any non-standard and unsupported changes you make to the way k-p works is your responsibility to fix. 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. Define just work. And the agreement I recall was codified on http://wiki.debian.org/KernelModulesPackaging Jonas and you wrote that one unilaterally despite my protests, i don't recognize that document. And since jonas seems to be kind-of MIA since a couple of weeks, this leaves only you. I am alive and well. Just tired of discussing with you, Sven. I am following this thread closely, and adding input only when needed - as I do now. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ - Enden er nær: http://www.shibumi.org/eoti.htm -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFDxGW6n7DbMsAkQLgRAs1EAKCn0NpqVp2pE/qcqgy1ns0QFUp2YQCfaN+R 7cQbYTEIhd+rH5LBVk1nlKs= =ExTI -END PGP SIGNATURE-
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 02:56:10AM +0100, Jonas Smedegaard wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 10 Jan 2006 23:53:03 +0100 Sven Luther [EMAIL PROTECTED] wrote: On Tue, Jan 10, 2006 at 04:00:00PM -0600, Manoj Srivastava wrote: On Tue, 10 Jan 2006 21:05:25 +0100, Sven Luther [EMAIL PROTECTED] said: On Tue, Jan 10, 2006 at 10:33:25AM -0600, Manoj Srivastava wrote: reassign 346281 linux-2.6 thanks Hi, If you have decided that putting the build link in headers is correct, then you get to fix this. The kernel-package tool does it dofferently, and while you are not required to follow what k-p does, any non-standard and unsupported changes you make to the way k-p works is your responsibility to fix. 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. Define just work. And the agreement I recall was codified on http://wiki.debian.org/KernelModulesPackaging Jonas and you wrote that one unilaterally despite my protests, i don't recognize that document. And since jonas seems to be kind-of MIA since a couple of weeks, this leaves only you. I am alive and well. Just tired of discussing with you, Sven. Well, this was the impression i got from the lack of new yaird upload, but hey, nice to see you around. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 [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
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 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. BTW, what about the image and headers both providing the build symlink, except for official images which will not, and using the alternatives mechanism, with the header symlink having the bigger priority ? This way everyone is happy, it just work, and the user can even override things. We still need to provide stong conflict between official packages and compiled from random source reusing the same name. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
reassign 346281 linux-image-2.6.15-1-686 thanks Hi On Fri, 06 Jan 2006 20:23:33 +0100, Ludovic Rousseau [EMAIL PROTECTED] said: Package: linux-image-2.6.15-1-686 Version: 2.6.15-1 Severity: normal I installed linux-headers-2.6.15-1-686 and then linux-image-2.6.15-1-686 and I get the debconf question about You are attempting to install a kernel image (version 2.6.15-1-686). However, the directory /lib/modules/2.6.15-1-686 still exists. The directory /lib/modules/2.6.15-1-686 exists but only contains (because linux-headers-2.6.15-1-686 is already installed): $ ls -al /lib/modules/2.6.15-1-686 total 8 drwxr-xr-x 2 root root 4096 2006-01-06 19:04 . drwxr-xr-x 14 root root 4096 2006-01-06 19:04 .. lrwxrwxrwx 1 root root 35 2006-01-06 19:04 build - /usr/src/linux-headers-2.6.15-1-686 Why is the kernel headers package still installing a build link? The Wiki article at http://wiki.debian.org/KernelModulesPackaging states that we shall use /usr/src/linux-headers-foo as KSRC, and when you install a kernel headers _and a kernel image (in any order), the build link shall be correctly set. Still shipping a build link in the headers package is a bug, and is not supported. kernel-package by itself does not ship a link in the headers package, but handles the link in the postinsts, so that the image and header packages do not have to conflict. manoj -- Living in LA is like not having a date on Saturday night. Candice Bergen Manoj Srivastava [EMAIL PROTECTED]http://www.golden-gryphon.com/ 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
Package: linux-image-2.6.15-1-686 Version: 2.6.15-1 Severity: normal I installed linux-headers-2.6.15-1-686 and then linux-image-2.6.15-1-686 and I get the debconf question about You are attempting to install a kernel image (version 2.6.15-1-686). However, the directory /lib/modules/2.6.15-1-686 still exists. The directory /lib/modules/2.6.15-1-686 exists but only contains (because linux-headers-2.6.15-1-686 is already installed): $ ls -al /lib/modules/2.6.15-1-686 total 8 drwxr-xr-x 2 root root 4096 2006-01-06 19:04 . drwxr-xr-x 14 root root 4096 2006-01-06 19:04 .. lrwxrwxrwx 1 root root 35 2006-01-06 19:04 build - /usr/src/linux-headers-2.6.15-1-686 Maybe the test could be improved to display the debconf question only if /lib/modules/2.6.15-1-686/kernel/ exists or, alternatively, if /lib/modules/2.6.15-1-686/build is _not_ the only file in /lib/modules/2.6.15-1-686/ Thanks, -- System Information: Debian Release: testing/unstable APT prefers testing APT policy: (500, 'testing'), (90, 'unstable'), (1, 'experimental') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.14-2-686 Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1) -- debconf information: linux-image-2.6.15-1-686/postinst/kimage-is-a-directory: linux-image-2.6.15-1-686/preinst/overwriting-modules-2.6.15-1-686: true linux-image-2.6.15-1-686/postinst/depmod-error-initrd-2.6.15-1-686: false linux-image-2.6.15-1-686/postinst/bootloader-error-2.6.15-1-686: linux-image-2.6.15-1-686/postinst/bootloader-test-error-2.6.15-1-686: linux-image-2.6.15-1-686/preinst/lilo-has-ramdisk: linux-image-2.6.15-1-686/preinst/failed-to-move-modules-2.6.15-1-686: linux-image-2.6.15-1-686/postinst/old-system-map-link-2.6.15-1-686: true linux-image-2.6.15-1-686/preinst/abort-install-2.6.15-1-686: linux-image-2.6.15-1-686/preinst/abort-overwrite-2.6.15-1-686: linux-image-2.6.15-1-686/preinst/bootloader-initrd-2.6.15-1-686: true linux-image-2.6.15-1-686/prerm/would-invalidate-boot-loader-2.6.15-1-686: true linux-image-2.6.15-1-686/preinst/lilo-initrd-2.6.15-1-686: true linux-image-2.6.15-1-686/postinst/old-initrd-link-2.6.15-1-686: true linux-image-2.6.15-1-686/postinst/old-dir-initrd-link-2.6.15-1-686: true linux-image-2.6.15-1-686/preinst/already-running-this-2.6.15-1-686: linux-image-2.6.15-1-686/preinst/initrd-2.6.15-1-686: linux-image-2.6.15-1-686/postinst/depmod-error-2.6.15-1-686: false linux-image-2.6.15-1-686/postinst/create-kimage-link-2.6.15-1-686: true linux-image-2.6.15-1-686/prerm/removing-running-kernel-2.6.15-1-686: true linux-image-2.6.15-1-686/preinst/elilo-initrd-2.6.15-1-686: true -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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
reassign 346281 kernel-package thanks This is to be solved in the kernel-package package, which provide the postinsts proposing this dialog and test, reassigning. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
