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

Bug#698012: debian-policy: Please update 10.6 "Device files" for udev and the like



Hello,

Trying to bring this old issue back to life. In recent years things
have changed so that it's not actually udev that creates the device
nodes anymore, but the kernel (via devtmpfs).

I don't think it's policys place to describe the actual implementation
details (which might change and we really don't care that much).
Instead only focus on if package maintainers needs to take special
care (like currently described in policy) or not (which is the
actual truth).

Some parts of 10.6 might still be considered useful (but I wonder if
anyone would actually violate it even if it wasn't there these days,
after all policy can't describe every way to get things wrong so maybe
the entire chapter should still be considered for removal).

This might still be useful:
"Packages must not include device files or named pipes in the package
file tree."

This (harmful advice) should just be removed:
"If a package needs any special device files that are not included in
the base system, it must call MAKEDEV in the postinst script, after
notifying the user."

Maybe still useful:
"Packages must not remove any device files in the postrm or any other
script. This is left to the system administrator."

Likely very outdated and probably not useful, but atleast not harmful:
"Debian uses the serial devices /dev/ttyS*. Programs using the old
/dev/cu* devices should be changed to use /dev/ttyS*."

This makes me cringe, in some cases I'd rather have them created on
demand:
"Named pipes needed by the package must be created in the postinst
script and removed in the prerm or postrm script as appropriate."
A simple fix would be to replace must by should, or add
alternatives to postinst/prerm mentioning "or created on demand, eg. via
unit files, init scripts, or similar".

My advice would be that if it's hard to find the perfect wording
for chapter 10.6, then start by removing the entire chapter now!
I think the current way does more harm than good.
After it has been removed there could be an issue opened where
new wording can be discussed.

Hopeing to see some progress made here soon. Please tell me if there's
anything more I can do to help move this issue forward.

Regards,
Andreas Henriksson


Reply to: