[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 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.
vorlon@debian.org                                   http://www.debian.org/

Attachment: signature.asc
Description: Digital signature

Reply to: