Bug#827704: udev is not portable and mandates kernel features

Pierre Ynard linkfanel at yahoo.fr
Mon Jun 20 18:13:25 BST 2016


> No: maintaining such a patch kit would take a huge amount of our time
> for a very small benefit.

Okay, I can understand that, but if the patch kit is pushed upstream
then it won't be a problem? If it can't, maybe you can please document
the reasons you just stated why it can't be fixed in the Debian
packaging, and why it can't be fixed upstream either, and why it
can't be forked or substituted with an alternative friendlier towards
portability and user choice and why everybody has to get stuck with this
package dictating its constraints around.

> I am not sure about what I should add: if you are, please feel free to
> send a patch to the upstream maintainers.

Ah, that README is from upstream, okay. As I mentioned, here's a list of
possible additional information:

- what accept4() is used for, SOCK_NONBLOCK and/or SOCK_CLOEXEC, and why
  it is so essential to udev operation that it's required and fcntl()
  can't be used instead

- what CONFIG_INOTIFY_USER is used for, to monitor which files or
  directories, and why it is so essential to udev operation that it's
  required

- what CONFIG_SIGNALFD is used for, to poll for and handle which
  signals, and why it is so essential to udev operation that it's
  required and can't be emulated

- what CONFIG_TIMERFD is used for, what is timer-based in a daemon that
  deals mostly with hotplug events, and why it is so essential to udev
  operation that it's required and can't be emulated

- what CONFIG_EPOLL is used for, which features would make it impossible
  to fall back on another polling API, and why it is so essential to
  udev operation that it's required

- why CONFIG_FHANDLE is so essential to udev operation that it's
  required

I don't know myself either what the answers to these questions are.
In fact, maybe I believe that there are just no good answers to these
questions to begin with, because the requirements are simply unwarranted
and inexcusable.

However, the preinst script is certainly within Debian packaging. Please
improve the output of the preinst check to make it sound less entitled
and outrageous to upgrading users, and explain to them why they're
getting requirements forced on them by a piece of software that can't
spare 3 lines of code to emulate something so inessential as accept4()
and mandates something as irrelevant as high-performance polling, in a
way that doesn't feel to them like a slap in the face.

-- 
Pierre Ynard
"Une âme dans un corps, c'est comme un dessin sur une feuille de papier."





More information about the Pkg-systemd-maintainers mailing list