On Mon, Feb 20, 2017 at 04:12:53PM -0800, Russ Allbery wrote:
> I propose the following section to completely replace this section.  This
> preserves what I think are the still-useful requirements while making it
> clear that nearly all packages should keep their hands off of /dev
> entirely.  It also takes notice of device files outside of /dev, which are
> more like named pipes than regular device files and which packages may
> need to create for various jailing reasons (like creating a /dev/null
> inside your file system namespace).
> 
> Comments, seconds?
> 
> (Also attached in the form of a patch.)
> 
>       <sect>
>       <heading>Device files</heading>
> 
>       <p>
>         Packages must not include device files or named pipes in the
>         package file tree.
>       </p>
> 
>       <p>
>         Debian packages should assume that device files
>         in <file>/dev</file> are dynamically managed by the kernel or
>         some other system facility and do not have to be explicitly
>         created or managed by the package.  Debian packages other than
>         those whose purpose is to manage the <file>/dev</file> device
>         file tree must not attempt to create or remove device files
>         in <file>/dev</file> when a dynamic device management facility
>         is in use.
>       </p>
> 
>       <p>
>         If named pipes or device files outside of <file>/dev</file> are
>         required by a package, they should normally be created when
>         necessary by the programs in the package, by init scripts or
>         systemd unit files, or by similar on-demand mechanisms.  If such
>         files need to be created during package installation, they must
>         be created in the <pgrn>postinst</pgrn> maintainer
>         script<footnote>
>           It's better to use <prgn>mkfifo</prgn> rather
>           than <prgn>mknod</prgn> to create named pipes to avoid false
>           positives from automated checks for packages incorrectly
>           creating device files.
>         </footnote>
>         and removed in either the <pgrn>prerm</pgrn> or
>         the <pgrn>postrm</pgrn> maintainer script.
>       </p>
>       </sect>
> 
> -- 
> Russ Allbery (r...@debian.org)               <http://www.eyrie.org/~eagle/>
> 

> From d575df9af106f837c3783e5c829abeef60484790 Mon Sep 17 00:00:00 2001
> From: Russ Allbery <r...@debian.org>
> Date: Mon, 20 Feb 2017 16:05:15 -0800
> Subject: [PATCH] Rewrite the Device files section
> 
> Remove the requirement to call MAKEDEV and prohibit attempting to
> create or remove device files if a dynamic management facility is in
> place.  Packages should assume device files in /dev are dynamically
> managed.  Point people towards dynamic creation of named pipes and
> document that creation in postinst is not the usual approach.  Extend
> that discussion to device files outside of /dev, which are required
> for some chroot or file system namespace approaches.
> 
> Remove the reference to old serial devices, which are now so old that
> it's highly unlikely anyone will care.
> ---
>  policy.sgml | 55 ++++++++++++++++++++++++-------------------------------
>  1 file changed, 24 insertions(+), 31 deletions(-)
> 
> diff --git a/policy.sgml b/policy.sgml
> index 200712a..4f02240 100644
> --- a/policy.sgml
> +++ b/policy.sgml
> @@ -9131,38 +9131,31 @@ ln -fs ../sbin/sendmail debian/tmp/usr/bin/runq
>       </p>
>  
>       <p>
> -       If a package needs any special device files that are not
> -       included in the base system, it must call
> -       <prgn>MAKEDEV</prgn> in the <prgn>postinst</prgn> script,
> -       after notifying the user<footnote>
> -           This notification could be done via a (low-priority)
> -           debconf message, or an echo (printf) statement.
> -       </footnote>.
> -     </p>
> -
> -     <p>
> -       Packages must not remove any device files in the
> -       <prgn>postrm</prgn> or any other script. This is left to the
> -       system administrator.
> -     </p>
> -
> -     <p>
> -       Debian uses the serial devices
> -       <file>/dev/ttyS*</file>. Programs using the old
> -       <file>/dev/cu*</file> devices should be changed to use
> -       <file>/dev/ttyS*</file>.
> -     </p>
> -
> -     <p>
> -       Named pipes needed by the package must be created in
> -       the <prgn>postinst</prgn> script<footnote>
> +       Debian packages should assume that device files
> +       in <file>/dev</file> are dynamically managed by the kernel or
> +       some other system facility and do not have to be explicitly
> +       created or managed by the package.  Debian packages other than
> +       those whose purpose is to manage the <file>/dev</file> device
> +       file tree must not attempt to create or remove device files
> +       in <file>/dev</file> when a dynamic device management facility
> +       is in use.
> +     </p>
> +
> +     <p>
> +       If named pipes or device files outside of <file>/dev</file> are
> +       required by a package, they should normally be created when
> +       necessary by the programs in the package, by init scripts or
> +       systemd unit files, or by similar on-demand mechanisms.  If such
> +       files need to be created during package installation, they must
> +       be created in the <pgrn>postinst</pgrn> maintainer
> +       script<footnote>
>           It's better to use <prgn>mkfifo</prgn> rather
> -         than <prgn>mknod</prgn> to create named pipes so that
> -         automated checks for packages incorrectly creating device
> -         files with <prgn>mknod</prgn> won't have false positives.
> -       </footnote> and removed in
> -       the <prgn>prerm</prgn> or <prgn>postrm</prgn> script as
> -       appropriate.
> +         than <prgn>mknod</prgn> to create named pipes to avoid false
> +         positives from automated checks for packages incorrectly
> +         creating device files.
> +       </footnote>
> +       and removed in either the <pgrn>prerm</pgrn> or
> +       the <pgrn>postrm</pgrn> maintainer script.
>       </p>
>        </sect>
>  
> -- 
> 2.11.0
> 

(Seems my previous reply dissapeared, so again...)

Seconded.

Regards,
Andreas Henriksson

Reply via email to