On Thu, Jul 07, 2005 at 08:23:03PM +0200, Marco d'Itri wrote:
> retitle 317332 udev 0.060-1 should be used with a >= 2.6.12 kernel
> thanks
>
> On Jul 07, Jakob Bohm <[EMAIL PROTECTED]> wrote:
>
> > Justification: breaks the whole system, will break upgrades from sarge
> Not really.
>
> > According to the NEWS entry provided in the udev 0.060-1 package itself,
> > this version of udev is NOT COMPATIBLE with any kernel version prior to
> > 2.6.12.
> NEWS.Debian ended out being a bit too much scary than it was intended.
> See http://blog.bofh.it/id_91 for details.
OK, so it was not as bad as stated for my 2.6.11 kernel (from unstable), but
the primary sarge kernel was 2.6.8, so 2.6.8 is the primary compatibility
requirement, while 2.6.11 is needed only for those tracking testing or
unstable!
What is worse however is the information about upstream in your blog.
Am I understanding you correctly when I read it as saying that kernel 2.6.12
(a point release in the "stable" branch) is making an incompatible change to
the udev interface, requires an upstream udev version which will not work on
relatively recent kernels (2.6.8 etc.) and (from info elsewhere)
simultaneously drops support for devfs (to which people just finished
migrating their locally written scripts ...)?
If this is correct, then this is the third such self-incompatible kernel
change in the last few months. The two others were a security patch that
broke modules compiled from the same kernel source (due to careless touching
of header files), and an ALSA user space library that could not
simultaneously support kernel 2.6.8 and kernel 2.6.10.
It seams that if getting udev 0.6x quickly rewritten to support all
udev-based kernels in one version is too much work or too controversial, you
should do what modutils, cdrecord and other packages usually do for *major*
kernel upgrades (like 2.4.x to 2.6.x): package two versions of the source,
two sets of binaries (in one .deb) and some wrapper scripts or binaries to
exec the right one depending on the kernel version.
That is create a package with a structure like this
udev-0.060/
debian/
(rules etc.)
debian/switch/
(the wrapper scripts to select the right udev)
v0.0??/
(unpacked copy of some older udev tarball for older kernels)
v0.058/
(unpacked copy of the 0.058 tarball plus Debian patches)
./
(upstream source not moved so pristine .orig.tar.gz still possible)
and from this create a package like this
/sbin/udev (result of
perl -p -e 's|NAME|udev|g; s|DIR|sbin|g;' <debian/switch/template)
/sbin/udev.0?? (result of compiling the v0.0?? source)
/sbin/udev.058 (result of compiling the v0.058 source)
/sbin/udev.06x (result of compiling the normal source)
(and similar for the other binaries)
Depending on differences in config file formats or interactions with other
packages, it may also be necessary to add some patches or script magic for
those too.
To correctly compile the different udev versions, you may need to depend on
some of the "real" kernel-header packages for various relevant kernel
versions.
Yes, it is sort of ugly, but it is also a clean solution:
- Each upstream version is compiled (almost) as it expects, including
contemporary kernel headers.
- The user and outside scripts work as if there was only one version
installed.
- The kernel works as if only the expected version was installed.
- There is only one .deb from a user and release perspective.
- It is easy for the udev maintainer (you) to rearrange the exact set of
historic versions and other package details without the user needing to
add or remove packages.
- Source unpacking is as for any normal package (nothing fancy like
embedded tars). .orig.tar.gz is pristine.
- If a new upstream version does not add new compatibility issues,
updating and rebuilding can be done as usual because of the clean patch
structure and directory isolation.
- There are no epochs or weird version number magic involved.
- Once udev matures to real stability and all unsupported kernels
are 2 Debian releases into the past, reverting to a straight udev
package without the extra versions is also trivial, because the general
package structure is still the same, just no extra dirs or wrapper
scripts. .patch.gz simply shrinks.
- There are no precompiled binaries in the "source", a build is still a
proper build from source.
Code hint:
/debian/switch/template could be something like
#!/bin/sh
set -e
case "$(/bin/uname -r)" in
[0-1].*|2.[012345].*)
ERR="This kernel not supported by this udev package"
;;
2.6.[0-7]|2.6.[0-7][!0-9]*)
exec /DIR/NAME.0?? "$@"
ERR="/DIR/NAME.0?? not found"
;;
2.6.[8-9]|2.6.[8-9][!0-9]*|2.6.1[0-1]|2.6.1[0-1][!0-9]*)
*)
exec /DIR/NAME.06x "$@"
ERR="/DIR/NAME.06x not found"
;;
esac
echo "/DIR/NAME: ${ERR}" >>/dev/console ||
echo "/DIR/NAME: ${ERR}" >&2 ||
:
[ -x /usr/bin/logger ] && /usr/bin/logger -i -t "NAME" -p 27 "${ERR}" || :
exit 1
# Hope no bashisms here...
# Note: This uses
# external program: /bin/uname
# optional external program: /usr/bin/logger
# shell builtins: set, case, esac, exec, echo, exit, :, [
# shell features: charset wildcards, $(), ${}, &&, ||, >>, >&2
# Note2: This script is optimized to minimize lines/commands before
# doing a successful exec
# also, no variables (not even PATH) are used or touched in the
# success case.
>
> > Furthermore, because kernel 2.6.12 or later is not included in the sarge
> > release, inclusion of this package version or any other udev not compatible
> > with the kernel versions actually in sarge will cause massive breakage to
> > users upgrading from sarge to etch or etch+1.
> An upgrade plan is being designed, but it is not really relevant to
> the kernel version requirements of this package.
>
> I will leave this bug open until 2.6.12 will be in etch.
>
Side note: I think that it is prudent to always have a clear upgrade plan
from stable to current upload, during the woody->sarge upgrade I was hit by
several (mostly minor) issues caused by relatively old changes that never
got the upgrade plan right, including just about every sarge package with a
NEWS file (support for displaying NEWS files was a post-woody feature, so
none of those upgrade instructions were displayed during the upgrade that
they addressed!).
--
This message is hastily written, please ignore any unpleasant wordings,
do not consider it a binding commitment, even if its phrasing may
indicate so. Its contents may be deliberately or accidentally untrue.
Trademarks and other things belong to their owners, if any.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
