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]
