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
