Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Wed, Aug 31, 2005 at 04:15:16PM +0200, Eduard Bloch wrote: For modules, you need to know what you are doing. Unfortunately the kernel developers seem to be ignorant WRT such things, gcc is hardcoded in assumption of beeing a never changing compatibility constant. Perhaps you could enlighten us ignorant kernel developers about this? Our mailing list (linux-kernel) is wide open... greg k-h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Tue, Aug 30, 2005 at 08:23:02PM -0400, Roberto C. Sanchez wrote: On Tue, Aug 30, 2005 at 04:59:48PM -0700, Steve Langasek wrote: Becuase I roll my own kernel. If I upgrade the kernel with gcc-3.3 (currently the Sarge default) and then upgrade to Etch (which will have gcc-4.0 for a default) I will run into problems if I decide to add new modules to my kernel. Thus, those with a self-compiled kernel are in a situation where you can a) dist-upgrade without first upgrading the kernel and risk breakage; or b) upgrade the kernel twice. Once before and once after. I suppose that it is possible to build the new kernel inside of a chroot (or sbuild or pbuilder) if kernel-package is being used. I am simply pointing out that there is a potential issue that needs to at least be addressed in the release notes. Ah, yes. I really don't understand why the kernel embeds the gcc version into its version-matching logic, but I've run into this problem as well. I agree that it warrants documenting, though I also suspect that most users running self-compiled 2.6 kernels are going to be running something a bit newer than 2.6.8 anyway. I also don't understand why the gcc version is an issue. I mean, you can compile a library with one version of gcc and link to it when compiling a program with a different version of gcc. We are even talking about C, which AFAICT doesn't suffer the same binary compatibility issues as C++. The kernel enables or disables many different things depending on the version of gcc to work around different issues. Because of this, the main kernel, and all kernel modules must be built with the exact same version of gcc, otherwise very bad things can happen. greg k-h -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Wed, Aug 31, 2005 at 01:59:26AM +0200, Marco d'Itri wrote: On Aug 31, Steve Langasek [EMAIL PROTECTED] wrote: If you aren't satisfied with the current solution, the answer is to figure out a better one rather than lamenting that no one else has. (I do have a This is where these threads usually end... With one of your terse one-liners? -- Horms -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Tue, Aug 30, 2005 at 08:23:02PM -0400, Roberto C. Sanchez wrote: Option a) doesn't seem particularly sensible to me, btw, because the risk is near certain... Incidentally, is it possible to put udev on hold, upgrade everything else, install a new kernel and then select udev for upgrade? Yes. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Aug 31, Horms [EMAIL PROTECTED] wrote: This is where these threads usually end... With one of your terse one-liners? With none of the complainers actually being useful to provide a better solution. -- ciao, Marco signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
#include hallo.h * Roberto C. Sanchez [Tue, Aug 30 2005, 01:06:39AM]: Why? Becuase I roll my own kernel. If I upgrade the kernel with gcc-3.3 (currently the Sarge default) and then upgrade to Etch (which will have gcc-4.0 for a default) I will run into problems if I decide to add new modules to my kernel. Thus, those with a self-compiled kernel are in a The compiler - kernel has always been there and has nothing to do with udev (or any other kernel-stuff-in-userspace troublemaker of the day). For modules, you need to know what you are doing. Unfortunately the kernel developers seem to be ignorant WRT such things, gcc is hardcoded in assumption of beeing a never changing compatibility constant. For additional modules packages using module-assistant there is a workaround that will push the right compiler into the path, but that is a cludge. It will fail with other module packages that just rely on the kernel build system and it will fail if you try to build some extra kernel modules without rebuilding the whole kernel and without manually forcing the kernel build system to use the correct gcc. Regards, Eduard. -- Wo haben wir denn das Dingens mit dem Dingens? -- Torsten Spindler
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Tue, Aug 30, 2005 at 10:16:27PM -0700, Greg KH wrote: On Tue, Aug 30, 2005 at 08:23:02PM -0400, Roberto C. Sanchez wrote: I also don't understand why the gcc version is an issue. I mean, you can compile a library with one version of gcc and link to it when compiling a program with a different version of gcc. We are even talking about C, which AFAICT doesn't suffer the same binary compatibility issues as C++. The kernel enables or disables many different things depending on the version of gcc to work around different issues. Because of this, the main kernel, and all kernel modules must be built with the exact same version of gcc, otherwise very bad things can happen. greg k-h Thanks for explaining. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpcRd29Vb0Nk.pgp Description: PGP signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
(pruning CC list; AFAIK all will still get the message this way) On Tuesday 30 August 2005 04:56, Steve Langasek wrote: So we're going to have another release with a very elaborate upgrade procedure in the release notes (which a lot of users, especially desktop users, don't read anyway)? 1) upgrade your kernel 2) dist-upgrade That doesn't seem terribly elaborate to me? And if people choose not to read, well, they get a failure on dist-upgrade and get to figure it out for themselves, I guess. Yeah, and that IMHO is exactly the problem. Debian used to be known for relatively trouble free upgrades. For the Woody-Sarge upgrade the upgrade problems (the kernel issues at least) were mostly limited to non-mainstream architectures, but now we're likely to hit 80% of Sarge desktop users. BTW, here's a first example... http://lists.debian.org/debian-boot/2005/08/msg01149.html (the poster works for Intel) pgpq3vH6GUVIh.pgp Description: PGP signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Tue, Aug 30, 2005 at 11:48:17PM +0200, Frans Pop wrote: (pruning CC list; AFAIK all will still get the message this way) On Tuesday 30 August 2005 04:56, Steve Langasek wrote: So we're going to have another release with a very elaborate upgrade procedure in the release notes (which a lot of users, especially desktop users, don't read anyway)? 1) upgrade your kernel 2) dist-upgrade That doesn't seem terribly elaborate to me? And if people choose not to read, well, they get a failure on dist-upgrade and get to figure it out for themselves, I guess. Yeah, and that IMHO is exactly the problem. Debian used to be known for relatively trouble free upgrades. For the Woody-Sarge upgrade the upgrade problems (the kernel issues at least) were mostly limited to non-mainstream architectures, but now we're likely to hit 80% of Sarge desktop users. No, failing to read the release notes for sarge and doing a blind dist-upgrade on a desktop system was also likely to rip out large swaths of packages in the process. I understand that we all want dist-upgrade to Just Work, but I don't see how complaining that the release notes contain important information that users ignore at their peril is different from complaining that the list of packages being removed on apt-get dist-upgrade contains important information that users ignore at their peril. If you aren't satisfied with the current solution, the answer is to figure out a better one rather than lamenting that no one else has. (I do have a vague idea of what this would entail, and I'm not willing to spend a month of my time on trying to make it work.) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Tue, Aug 30, 2005 at 01:06:39AM -0400, Roberto C. Sanchez wrote: On Mon, Aug 29, 2005 at 09:43:33PM -0700, Steve Langasek wrote: 1) upgrade your kernel 2) dist-upgrade That doesn't seem terribly elaborate to me? And if people choose not to read, well, they get a failure on dist-upgrade and get to figure it out for themselves, I guess. Will that still apply in the case of a home-rolled kernel? Yes, of course. The reason this is such an issue in the first place is because kernel dependencies are *not* expressed as package dependencies; instead, udev checks the running kernel version in the preinst. Thanks for the clarification. However, if you have to compile your own kernel, do you upgrade kernel, dist-upgrade and then recompile with the new gcc? Why? Becuase I roll my own kernel. If I upgrade the kernel with gcc-3.3 (currently the Sarge default) and then upgrade to Etch (which will have gcc-4.0 for a default) I will run into problems if I decide to add new modules to my kernel. Thus, those with a self-compiled kernel are in a situation where you can a) dist-upgrade without first upgrading the kernel and risk breakage; or b) upgrade the kernel twice. Once before and once after. I suppose that it is possible to build the new kernel inside of a chroot (or sbuild or pbuilder) if kernel-package is being used. I am simply pointing out that there is a potential issue that needs to at least be addressed in the release notes. Ah, yes. I really don't understand why the kernel embeds the gcc version into its version-matching logic, but I've run into this problem as well. I agree that it warrants documenting, though I also suspect that most users running self-compiled 2.6 kernels are going to be running something a bit newer than 2.6.8 anyway. Option a) doesn't seem particularly sensible to me, btw, because the risk is near certain... -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Aug 31, Steve Langasek [EMAIL PROTECTED] wrote: If you aren't satisfied with the current solution, the answer is to figure out a better one rather than lamenting that no one else has. (I do have a This is where these threads usually end... -- ciao, Marco signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Tue, Aug 30, 2005 at 04:59:48PM -0700, Steve Langasek wrote: Becuase I roll my own kernel. If I upgrade the kernel with gcc-3.3 (currently the Sarge default) and then upgrade to Etch (which will have gcc-4.0 for a default) I will run into problems if I decide to add new modules to my kernel. Thus, those with a self-compiled kernel are in a situation where you can a) dist-upgrade without first upgrading the kernel and risk breakage; or b) upgrade the kernel twice. Once before and once after. I suppose that it is possible to build the new kernel inside of a chroot (or sbuild or pbuilder) if kernel-package is being used. I am simply pointing out that there is a potential issue that needs to at least be addressed in the release notes. Ah, yes. I really don't understand why the kernel embeds the gcc version into its version-matching logic, but I've run into this problem as well. I agree that it warrants documenting, though I also suspect that most users running self-compiled 2.6 kernels are going to be running something a bit newer than 2.6.8 anyway. I also don't understand why the gcc version is an issue. I mean, you can compile a library with one version of gcc and link to it when compiling a program with a different version of gcc. We are even talking about C, which AFAICT doesn't suffer the same binary compatibility issues as C++. As far as running newer self-compiled kernels, that certainly is not the case for me. In fact, I only compile my own kernel becuase I require the mppe patch on my machines. If not for that, I would be running a stock kernel because I have been bitten in the past by staying on the bleeding edge. I know that I am only one data point, but I am sure that I am not the only one. Option a) doesn't seem particularly sensible to me, btw, because the risk is near certain... Incidentally, is it possible to put udev on hold, upgrade everything else, install a new kernel and then select udev for upgrade? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpsZCEqDzQC6.pgp Description: PGP signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Aug 31, Roberto C. Sanchez [EMAIL PROTECTED] wrote: Incidentally, is it possible to put udev on hold, upgrade everything else, install a new kernel and then select udev for upgrade? Everything else which does not depend on the new version of conflicts with the old version, which will be a lot of packages (among them everything which depends on HAL). -- ciao, Marco signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Aug 29, Sven Luther [EMAIL PROTECTED] wrote: Did you really need to make such a mess about this ? Yes, but thank you for asking about it. -- ciao, Marco signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 10:22:59AM +0200, Marco d'Itri wrote: On Aug 29, Horms [EMAIL PROTECTED] wrote: Can this be resolved by some dependancies and conflicts? This is supposed to be a FAQ: packages cannot have explicit dependencies on kernel packages. While doing breakage things in the postinst is allowed ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 01:46:49AM +0200, Marco d'Itri wrote: Package: udev,linux-2.6 Severity: grave udev = 0.060-1 and kernels = 2.6.12 should enter testing at the same time. If udev is first it will refuse to be upgraded (or install but disable itself on new installs), if the kernel is first some udev rules (at least the ones referencing sysfs attributes) will not work. Monitor the situation at: http://bjorn.haxx.se/debian/testing.pl?package=linux-2.6 http://bjorn.haxx.se/debian/testing.pl?package=udev and close this bug when both packages will be ready to enter testing at the same time. Alsa-utils in testing currently doesn't install with udev in testing, and furthermore upgrades of udev is utherly broken. Udev installation will die when running a kernel 2.6.12, but old udev will be broken when running a 2.6.12 kernels as far as i understand, this leads to a udev created circular deadlock, which is much less than user friendly, and which should be solved in a nicer manner. MAybe you could have udev install complete when upgrading to 2.6.12/new udev, but not be activated or such. Did you really need to make such a mess about this ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 10:54:59AM +0200, Marco d'Itri wrote: On Aug 29, Sven Luther [EMAIL PROTECTED] wrote: Did you really need to make such a mess about this ? Yes, but thank you for asking about it. Well, badly worded maybe :), but i think your RC bug on the kernel without prior discussion may have been somewhat rude. Anyway, i was expecting some explanation about the reason why this mess happened, especially in the light of you asking for help on a neater solution. In any case, i belive the current situation, in that it breaks the sarge-etch migration, will have to be fixed down the line, so we should maybe best do it now cleanly. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 11:04:18AM +0200, Marco d'Itri wrote: On Aug 29, Sven Luther [EMAIL PROTECTED] wrote: Well, badly worded maybe :), but i think your RC bug on the kernel without prior discussion may have been somewhat rude. It was discussed with vorlon. Vorlon is not the kernel team however. Anyway, i was expecting some explanation about the reason why this mess happened, especially in the light of you asking for help on a neater solution. I am not actually asking for help, because I have spent a large quantity of my time dealing with this and so far I believe that there are no better solutions. But I am allowing people who think they know better to propose other solutions (at the obvious risk of being flamed if they did not do their homeworks first). Thanks all the same for that much cooperation. What do you think of having two udev packages, which are parallely installable, and one would work for 2.6.12 and the other for 2.6.12 ? In any case, i belive the current situation, in that it breaks the sarge-etch It does not. The agreed transition procedure is: * upgrade the kernel Which breaks currently installed udev. * reboot * upgrade udev This is definitively not a user-friendly procedure. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Aug 29, Sven Luther [EMAIL PROTECTED] wrote: It was discussed with vorlon. Vorlon is not the kernel team however. But he is the one who decides when packages should or should not go in testing, which is what this bug is about. What do you think of having two udev packages, which are parallely installable, and one would work for 2.6.12 and the other for 2.6.12 ? Please *first* read the closed udev bugs about this and *then* propose solutions. * upgrade the kernel Which breaks currently installed udev. Only partially, it will work enough to allow rebooting and upgrading. -- ciao, Marco signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Aug 29, Sven Luther [EMAIL PROTECTED] wrote: Well, badly worded maybe :), but i think your RC bug on the kernel without prior discussion may have been somewhat rude. It was discussed with vorlon. Anyway, i was expecting some explanation about the reason why this mess happened, especially in the light of you asking for help on a neater solution. I am not actually asking for help, because I have spent a large quantity of my time dealing with this and so far I believe that there are no better solutions. But I am allowing people who think they know better to propose other solutions (at the obvious risk of being flamed if they did not do their homeworks first). In any case, i belive the current situation, in that it breaks the sarge-etch It does not. The agreed transition procedure is: * upgrade the kernel * reboot * upgrade udev -- ciao, Marco signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 11:15:22AM +0200, Marco d'Itri wrote: On Aug 29, Sven Luther [EMAIL PROTECTED] wrote: It was discussed with vorlon. Vorlon is not the kernel team however. But he is the one who decides when packages should or should not go in testing, which is what this bug is about. Yeah, sure, whatever ... What do you think of having two udev packages, which are parallely installable, and one would work for 2.6.12 and the other for 2.6.12 ? Please *first* read the closed udev bugs about this and *then* propose solutions. Well, i know you close RC bugs on a whim, so ... * upgrade the kernel Which breaks currently installed udev. Only partially, it will work enough to allow rebooting and upgrading. In all cases ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Monday 29 August 2005 11:06, Sven Luther wrote: * reboot * upgrade udev This is definitively not a user-friendly procedure. In effect this means that any user having udev installed will have to put udev on hold. Because of versioned dependencies on udev, this will probably make a lot of other installed packages not upgradable. The kernel is likely going to be upgraded automatically because users will be using the kernel-image-2.6-xxx packages. So we're going to have another release with a very elaborate upgrade procedure in the release notes (which a lot of users, especially desktop users, don't read anyway)? I agree with Sven. This is definitely not user-friendly. If this really does have to happen this way, the user should be somehow presented with instructions to do this properly during the upgrade. Cheers, FJP pgpVXx64B9RpN.pgp Description: PGP signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Aug 29, Frans Pop [EMAIL PROTECTED] wrote: In effect this means that any user having udev installed will have to put udev on hold. No, if the kernel has not been upgraded yet then preinst will fail. If this really does have to happen this way, the user should be somehow presented with instructions to do this properly during the upgrade. Sure, this can be arranged when we will be closer to the release. -- ciao, Marco signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 03:06:04AM -0700, Steve Langasek wrote: On Mon, Aug 29, 2005 at 11:26:09AM +0200, Bastian Blank wrote: reassign 325484 udev retitle 325484 udev lacks sarge-etch upgrade path thanks On Mon, Aug 29, 2005 at 01:46:49AM +0200, Marco d'Itri wrote: udev = 0.060-1 and kernels = 2.6.12 should enter testing at the same time. You have to provide a proper sarge-etch upgrade path. This bug is the sign of lack this path. Requiring that users reboot to 2.6.12 before installing the new version of udev from etch *is* a valid upgrade path. There were similar upgrade path choices that had to be made for woody-sarge on some archs due to kernel/glibc incompatibilities between versions; the udev upgrade path provided is not really any different than that, and unless someone can show a working implementation for udev that doesn't require this, I don't intend to second-guess Marco on this issue. BTW, you are aware of the etch situation concerning alsa-utils and udev not being co-installable ? Of course, we want udev 0.060 and linux-2.6 to be available at the same time in each suite, because dealing with the udev preinst failure is still disruptive -- we want users to install the kernel update *first*. I don't understand this, if having the wrong udev for your kernel is only minorly disruptiuve, why this anoying preinst rule ? I mean, i have tried to do a couple of times in the past days and upgrade from sarge to sid kernels, and always udev complained when i upgraded kernels, while they should have been installed both at the same time. This bug was opened to ensure that. Marco, since it looks like udev is going to be ready to go into testing before linux-2.6, and the breakage of new udev with old kernel is much worse than the breakage of old udev with new kernel, I think it would be a good idea to keep a bug open on udev for right now, even if the kernel maintainers object to having it listed against linux-2.6. It would also be nice for Marco to be a bit more cooperative next time such situation arise. Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Aug 29, Sven Luther [EMAIL PROTECTED] wrote: Of course, we want udev 0.060 and linux-2.6 to be available at the same time in each suite, because dealing with the udev preinst failure is still disruptive -- we want users to install the kernel update *first*. I don't understand this, if having the wrong udev for your kernel is only minorly disruptiuve, why this anoying preinst rule ? I mean, i have tried to Because the opposite is not true, and recent udev versions do not work with old kernels. It would also be nice for Marco to be a bit more cooperative next time such situation arise. I think I have been very cooperative, but I'm not going to be the scapegoat of people who did not bother investigating how udev works. -- ciao, Marco signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 03:04:18PM +0200, Marco d'Itri wrote: On Aug 29, Sven Luther [EMAIL PROTECTED] wrote: Of course, we want udev 0.060 and linux-2.6 to be available at the same time in each suite, because dealing with the udev preinst failure is still disruptive -- we want users to install the kernel update *first*. I don't understand this, if having the wrong udev for your kernel is only minorly disruptiuve, why this anoying preinst rule ? I mean, i have tried to Because the opposite is not true, and recent udev versions do not work with old kernels. Ah, ok. It would also be nice for Marco to be a bit more cooperative next time such situation arise. I think I have been very cooperative, but I'm not going to be the scapegoat of people who did not bother investigating how udev works. Well, i meant cooperative, as in discussing this kind of things in the debian-kernel mailing list, which is the natural place for it, don't you think ? Just make sure you think about this next time, ok ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Monday 29 August 2005 12:35, Marco d'Itri wrote: On Aug 29, Frans Pop [EMAIL PROTECTED] wrote: In effect this means that any user having udev installed will have to put udev on hold. No, if the kernel has not been upgraded yet then preinst will fail. Hmm. Won't that fail the whole dist-upgrade? If this really does have to happen this way, the user should be somehow presented with instructions to do this properly during the upgrade. Sure, this can be arranged when we will be closer to the release. Great. pgpyqFIWFUtrZ.pgp Description: PGP signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 11:35:03PM -0400, Roberto C. Sanchez wrote: On Mon, Aug 29, 2005 at 07:56:32PM -0700, Steve Langasek wrote: The kernel is likely going to be upgraded automatically because users will be using the kernel-image-2.6-xxx packages. Is that a problem for some reason? So we're going to have another release with a very elaborate upgrade procedure in the release notes (which a lot of users, especially desktop users, don't read anyway)? 1) upgrade your kernel 2) dist-upgrade That doesn't seem terribly elaborate to me? And if people choose not to read, well, they get a failure on dist-upgrade and get to figure it out for themselves, I guess. Will that still apply in the case of a home-rolled kernel? Yes, of course. The reason this is such an issue in the first place is because kernel dependencies are *not* expressed as package dependencies; instead, udev checks the running kernel version in the preinst. However, if you have to compile your own kernel, do you upgrade kernel, dist-upgrade and then recompile with the new gcc? Why? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 01:56:10PM +0200, Sven Luther wrote: On Mon, Aug 29, 2005 at 03:06:04AM -0700, Steve Langasek wrote: Requiring that users reboot to 2.6.12 before installing the new version of udev from etch *is* a valid upgrade path. There were similar upgrade path choices that had to be made for woody-sarge on some archs due to kernel/glibc incompatibilities between versions; the udev upgrade path provided is not really any different than that, and unless someone can show a working implementation for udev that doesn't require this, I don't intend to second-guess Marco on this issue. BTW, you are aware of the etch situation concerning alsa-utils and udev not being co-installable ? Yes. Unfortunately, the issue wasn't raised until the new version of alsa-utils had already reached testing. On Mon, Aug 29, 2005 at 12:21:43PM +0200, Frans Pop wrote: On Monday 29 August 2005 11:06, Sven Luther wrote: * reboot * upgrade udev This is definitively not a user-friendly procedure. In effect this means that any user having udev installed will have to put udev on hold. Because of versioned dependencies on udev, this will probably make a lot of other installed packages not upgradable. Well, yes. That would be a consequence of choosing not to upgrade to the current 2.6 kernel version (the version which will quite shortly become the only officially supported 2.6 kernel in testing). But I don't see anybody stepping forward to implement a prettier solution, so these consequences, though unpleasant, are still acceptable. The kernel is likely going to be upgraded automatically because users will be using the kernel-image-2.6-xxx packages. Is that a problem for some reason? So we're going to have another release with a very elaborate upgrade procedure in the release notes (which a lot of users, especially desktop users, don't read anyway)? 1) upgrade your kernel 2) dist-upgrade That doesn't seem terribly elaborate to me? And if people choose not to read, well, they get a failure on dist-upgrade and get to figure it out for themselves, I guess. I agree with Sven. This is definitely not user-friendly. If this really does have to happen this way, the user should be somehow presented with instructions to do this properly during the upgrade. Yes, they should; but the right answer is still to do step 1) before step 2), because having your dist-upgrade fail partway through is *always* the messy option -- it's just a better option than having your dist-upgrade *not* fail, and leave you instead with a broken system. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 07:56:32PM -0700, Steve Langasek wrote: The kernel is likely going to be upgraded automatically because users will be using the kernel-image-2.6-xxx packages. Is that a problem for some reason? So we're going to have another release with a very elaborate upgrade procedure in the release notes (which a lot of users, especially desktop users, don't read anyway)? 1) upgrade your kernel 2) dist-upgrade That doesn't seem terribly elaborate to me? And if people choose not to read, well, they get a failure on dist-upgrade and get to figure it out for themselves, I guess. Will that still apply in the case of a home-rolled kernel? If you use the Debian-provided kernel, then you will have a kernel on your system that is compiled with the default version of gcc that is in Etch. However, if you have to compile your own kernel, do you upgrade kernel, dist-upgrade and then recompile with the new gcc? -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgpxofbipnJDF.pgp Description: PGP signature
Bug#325484: udev = 0.060-1 and kernels = 2.6.12
On Mon, Aug 29, 2005 at 09:43:33PM -0700, Steve Langasek wrote: 1) upgrade your kernel 2) dist-upgrade That doesn't seem terribly elaborate to me? And if people choose not to read, well, they get a failure on dist-upgrade and get to figure it out for themselves, I guess. Will that still apply in the case of a home-rolled kernel? Yes, of course. The reason this is such an issue in the first place is because kernel dependencies are *not* expressed as package dependencies; instead, udev checks the running kernel version in the preinst. Thanks for the clarification. However, if you have to compile your own kernel, do you upgrade kernel, dist-upgrade and then recompile with the new gcc? Why? Becuase I roll my own kernel. If I upgrade the kernel with gcc-3.3 (currently the Sarge default) and then upgrade to Etch (which will have gcc-4.0 for a default) I will run into problems if I decide to add new modules to my kernel. Thus, those with a self-compiled kernel are in a situation where you can a) dist-upgrade without first upgrading the kernel and risk breakage; or b) upgrade the kernel twice. Once before and once after. I suppose that it is possible to build the new kernel inside of a chroot (or sbuild or pbuilder) if kernel-package is being used. I am simply pointing out that there is a potential issue that needs to at least be addressed in the release notes. -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto pgp1WLSlJoGyw.pgp Description: PGP signature
