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

Re: Bug#551140: udev preinstall script fails if kernel doesn't have inotify

There are two problems:
- kernel versions
- configuration of kernel

The first one is a nightmare to solve properly and IMHO we
can still require some brain and manual tweak of admins.
One solution is to have (like old modutils and kernel modules)
different programs for different kernels, but this will be
a maintenance nightmare for us.

But the main concern is the second one: what we should require
from (self-compiled) kernels. IMHO we should finally document
the minimal setups for self-compiled kernel and ev. document in
release note any additional requirements.

Why should we handle differently not having inotify as not
having ELF support or procfs support or sysfs support or acct
(for acct package)? Sometime new debian releases need new kernel
features (and this is not a news) so IMHO we should only document
it better and let the self-compiling admin to take the
appropriate step before to upgrade packages.

PS: A /usr/doc/share/udev/NEWS.Debian.gz is a nice place
to put additional (for udev) requirements, and careful admins
will check it (maybe with apt-listchanges) before proceding to
the real installation of the packages.


Marco d'Itri wrote:
Any opinions?

This ONLY MATTERS if the user is using a self-compiled kernel, upgrades
of Debian kernel packages are automatically detected.

----- Forwarded message from Greg Alexander <debgreg@galexander.org> -----

From: Greg Alexander <debgreg@galexander.org>
To: Marco d'Itri <md@Linux.IT>
Subject: Re: Bug#551140: udev preinstall script fails if kernel doesn't
	have inotify

Please clarify the difference between the following two scenarios.

- admin tries to upgrade udev, preinst fails
- admin upgrades the kernel
- reboot
- admin upgrades udev

- admin tries to upgrade udev, preinst fails
- admin creates /etc/udev/kernel-upgrade
- admin upgrades the kernel and udev, and hopefully nothing else
- reboot (*immediate*, because udev the old udev is still running)

Ah, good.

Dependency satisfaction.  I upgraded a core package (I believe libc6), to
discover that it had an undeclared dependency on a newer version of dpkg
(or one of the dpkg-associated utilities), causing it to fail to install
completely (but it did install partially, since it was an undeclared
dependency...it errored out in a setup script).  As a result, until I
processed all of dpkg's dependencies (with apt-get -f install), I had a
halfway installed libc6.  Probably it would have been safe to reboot with
this halfway installed libc6, but I prefer not to chance it.

I first installed Debian on this computer in 2003 and have haphazardly
updated it off of debian-unstable since then.  This sort of dependency
nightmare is common with 5 year old debian installations.  Each time I
run through a big batch of updates, I have to do this little dance.
Most packages upgrade without incident.  Some present unnecessary
stumbling blocks.  This year, it is udev.  You could say it was libc6
that really caused the problem, but the usual apt tools for dealing with
this situation were sufficient to address libc6's issue, but not udev's.

- Greg

----- End forwarded message -----

Reply to: