Abridged to remove irrelevant conversation…
< Czesiu> Btw, udev recommends at least 2.6.12 kernel, which is not shipped
in Debian.
< Md> so far the upgrade procedure is “upgrade your kernel, reboot,
upgrade udev”
< Md> Czesiu: yeah, nobody had told me this yet, you know?
< dilinger> you can either go the lvm route, and make up some kernel APIs to
match again, or you can go the ndiswrapper route and make some incredibly
strict dependencies so that people are sure to upgrade kernels and udev
in parallel. both solutions suck.
< Czesiu> Md: you sound quite sarcastic :)
< wildfire> why not just have a udev-compat; which conflicts which newer
kernels; and make udev conflict with older ones
< Md> dilinger: a future udev version will refuse to install on anything
older than 2.6.12, so this will reduce the potential for brokeness
< Md> the /dev/input/mice problem has been unexpected, if it cannot be fixed
I will make the next package require 2.6.12
< dilinger> the best solution, imo, is to have udev 0.5x and 0.62 allowed
to be installed in parallel, and have a wrapper script that determines which
to use when it’s run
< wildfire> hmm, dilinger, that does sound pretty clean
< Md> dilinger: the configuration syntax is subtly different too. this is
not really possible
< Md> wildfire: yes, until you start looking at how to implement it
< dilinger> Md: sure it is; /etc/udev05x for the old version or something
< dilinger> /etc/udev for the new version
< wildfire> md, but that’s someone else problem ;-)
< Md> dilinger: keeping them in sync is hell
< dilinger> no kidding, but that’s what maintaining stuff like this requires
< Md> so far, it appears to be too much complex to be justified
< Md> if upgrades will happen to be more complex than we currently know then
I will reconsider this
< dilinger> are you kidding? i think the number of people whose systems
are breaking is pretty good justification
< Md> dilinger: only because the package currently is not refusing to run
on older kernels
< idnar> Md: but if the package fails to run, isn’t that likely to cause
breakage too, since your /dev won’t look like it normally does?
< Md> idnar: it will refuse to be installed or upgraded, like it’s currently
happening if you are using a kernel < 2.6.8
< dilinger> Md: what about doing something insane w/ devfs/
< dilinger> and devfsd
< Md> dilinger: ?
< idnar> Md: ah
< dilinger> depend upon devfsd, if the kernel is older than 2.6.12, have it
mount devfs over /dev and run devfsd instead of runing udev
< Md> different configuration syntax, different semantics, no HAL/hotplug
support. basically, I can’t see why you could think about this
< dilinger> because it would allow things to *work*
< dilinger> even if it doesn’t have the same config syntax
< dilinger> it could spit out a big warning upon startup
< idnar> suddenly switching the user to devfs would likely cause all sorts
of unknown breakage
< Md> if the kernel is older than 2.6.12 people will not be able to install
a newer udev, so this is not relevant
< Md> please try to look at the whole picture
< dilinger> people are going to want to reboot into older kernels and have
their /dev in a sane state
< dilinger> the running kernel isn’t the only one they may be using
< Clint> yeah, i’m not using the running kernel
< Md> dilinger: then udev will automatically disable itself. the current
experience shows that users are not bothered by this
< dilinger> Clint: quiet over there :P
< dilinger> Md: the user experiences around here don’t seem to match what
you’re saying, otherwise i wouldn’t even be mentioning it
< Md> again, this is not how future versions will work
< dilinger> let me put it another way
< dilinger> it would be a very good idea to future proof udev against such
incompatabilities now
< Md> tell greg k-h, now me :-)
< dilinger> because i’m sure things will break again
< Md> anyway, you persuaded me. I will upload right now an updated package
which refuses to be installed with old kernels
< Md> * Kernels older than 2.6.12 are not supported anymore.
< Md> If detected, the package will refuse to be installed.
< Md> If the running kernel is downgraded after the package has been
< Md> installed udev will disable itself at boot time.
< Sesse> Md: whoa
< joshk> that’s ridiculously stupid if you as me
< Md> this is what was going to happen in a few releases anyway
< Clint> joshk: coredump immediately
< Md> BTW, I suggest that concerned people read this before continuing
http://sourceforge.net/mailarchive/message.php?msg_id=12236847
< joshk> breaking support for anything but the very latest kernel (which
isn’t even in debian yet!) is dumb. you break everyone’s desktop because
hal stops working
< joshk> (one particular example)
< Md> joshk: people can keep the old udev until the upgrade, nothing breaks
< Sesse> Md: *g*
< joshk> don’t grin at Md, it makes him think we’re in agreement