Package: udev Version: 230-2 Severity: wishlist When trying to upgrade udev from version 175-7.2 to 230-2, I get greeted by the:
> Since release 198, udev requires support for the following features in > the running kernel: > > - inotify(2) (CONFIG_INOTIFY_USER) > - signalfd(2) (CONFIG_SIGNALFD) > - accept4(2) > - open_by_handle_at(2) (CONFIG_FHANDLE) > - timerfd_create(2) (CONFIG_TIMERFD) > - epoll_create(2) (CONFIG_EPOLL) Thank you for the preinst check and documenting in more details in the README. However, some of these requirements seem unwarranted, backwards and frankly outrageous. Decent software should make a minimum effort at portability, and not direct the underlying system around. - accept4() can be trivially emulated on ENOSYS. Any portable software will do that trivial job. I don't believe that SOCK_CLOEXEC race conditions would be a crippling issue for udev. - epoll is just one out of many polling APIs. Any portable software will fall back onto more common APIs like poll() or even select(), and wrap around them or emulate missing features. Frankly, mandating epoll like there's no way around it is simply appalling. epoll has main scaling and performance purposes, but polling performance does not seem to be any relevant for udev, really. - timerfd_create() and signalfd() are just convenience APIs around the more pervasive mechanisms of timers and signal handling. Equivalent functionality can be emulated with a handler that writes into a pipe; at any rate, they do not seem required to do the job. I don't need to delve into the other items because the point is already clear. I can understand mandating stuff like CONFIG_DEVTMPFS, since it's actually a major feature core to udev business, and would even be a paradigm shift. I can understand mandating CONFIG_SYSFS_DEPRECATED=n since that's within core udev business too. But most of the items above have nothing particular to do with udev, and are just generic APIs. Generic API availability gets properly managed, detected, emulated or gracefully handled in portable software, not mandated; and the more generic and trivial the API, the less understandable it is. For the sake of openness, the feature missing on my system is CONFIG_FHANDLE. It's not hidden under CONFIG_EXPERT like some others, and the current Linux kernel Kconfig help only mentions "userspace file servers", not a system component like udev, so I did not think much of it. I can vaguely imagine how it would be useful (although not necessary) to udev, and I don't really mind enabling it, but this is not this point of the bug report - the principle is. Please improve the portability of udev and reduce or eliminate the above list of required non-essential features. udev is a basic package that would be installed on most systems. On mine, it still remains depended on by X.Org (for very understandable reasons); it cannot be removed, nor substituted by any alternative. As such, anything the udev package imposes has consequences that take away user choice on a distribution-wide scale. Please provide and/or document the ability to remove udev or substitute alternatives for it. As a last resort, please make this apparent lack of portability more understandable for users. The information in the README is a very good start already, I appreciate it, but please complete it to document what requires the features in the above list and foremost why they are essential. Lack of portability, and mandating features in other system components from such a basic and pervasive package, set a bad example for software; please document, explain and present in a more understandable way this approach and its outstanding, exceptional and/or discouraged character. Please improve the most visible part of it, the output of the preinst check, to make it sound less entitled and outrageous to upgrading users, especially in view of some of the required features in the list. After taking care of this bug report I'm looking forward to being able to upgrade udev, I hope I won't run into any more hurdle. The changelog looks good, and I'm looking forward to being able to disable CONFIG_UEVENT_HELPER :) Thanks, -- System Information: Debian Release: stretch/sid APT prefers unstable APT policy: (500, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 4.4.6-grsec (SMP w/4 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: sysvinit (via /sbin/init) Versions of packages udev depends on: ii debconf [debconf-2.0] 1.5.59 ii libc6 2.22-11 ii libselinux1 2.5-3 ii libudev0 175-7.2 ii lsb-base 9.20160601 ii procps 2:3.3.11-3 ii util-linux 2.28-5 Versions of packages udev recommends: ii pciutils 1:3.3.1-1.1 ii usbutils 1:007-4 udev suggests no packages. -- debconf information: udev/title/upgrade: udev/reboot_needed: udev/new_kernel_needed: false udev/sysfs_deprecated_incompatibility: