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

DEBIAN POLICY WEEKLY, Issue #3 (August 18, 1997)



-----BEGIN PGP SIGNED MESSAGE-----


DEBIAN POLICY WEEKLY, #3 (August 18, 1997)

The following message is a list of topics related to the Debian Policy which
are currently under discussion or which will be discussed in the near
future. This summary is sent to the debian-policy mailing list periodically
by the Debian Policy Manager.

A copy of this mail is sent to debian-devel to keep other developers
up-to-date. Please send any replies to the debian-policy mailing list.

Please do not quote the whole mail if you are only referring to a single
section to save bandwidth.

- ----------------------------------------------------------------------------

The Policy Manual on the Web

This message can also be read online at

   http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-policy/weekly/

The Home Page of the Debian Policy Manual can be visited at

   http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-policy/

This page contains links to the current documents, information about the
current development version (2.3.0.0 DRAFT), and links to related documents.

- ----------------------------------------------------------------------------

Current discussion topics

The following topics are currently under discussion or will be discussed in
the near future.

Each topic has a `state' (APPROVED, APPROVAL, INPUT, DISCUSSION) which
represents the state of the discussion. (For example, a new idea will
probably show up with state `DISCUSSION'. If a policy change is prepared,
the state will become `APPROVAL', and finally `APPROVED'.)

Topics with state `APPROVED' or `APPROVAL' are already included in the draft
versions of the Policy Manual (check out the home page of the Policy
Manual).

Topics with state: APPROVED

The following policy changes have already been approved and will become
official with the next release of the policy manual:

     1. new non-free/contrib policy

Topics with state: APPROVAL

The following policy changes have been developed during discussions on these
topics. If there are no objections, these changes will be included in the
next version of the Policy Manual:

     2. netbase's configuration files

     3. tcl/tk virtual packages

     4. policy for MTA's file locking

     5. perl module policy

     6. configuration files

Topics with state: INPUT

I need more technical information about the following topics to prepare a
policy change:

     7. UUCP-locking of devices

     8. documentation policy

     9. starting daemons in the postinst scripts

     10. usage of `must' and `should' in the manual

Topics with state: DISCUSSION

The following ideas were mentioned in recent discussions and will be
discussed in the near future:

     11. Pristine sources

     12. where to install non-english docs

     13. secure admin scripts

     14. X Window Manager policy

- ----------------------------------------------------------------------------

Topic 1: new non-free/contrib policy

STATE: APPROVED
INFO:  Note, that the requirements for the /usr/doc/pkg/copyright files
have been lowered slightly, since the announcement of a policy change
on debian-private.

The Debian project leader, policy manager, and archive manager have
followed the developer's debate on contrib and non-free policy, and
have reached a consensus about changing the policy requirements that
packages in the different distribution directories have to comply
with.

With the new policy, it will be possible to continue distributing
"contrib" on the Official Debian CD, the Official CD will become
entirely DFSG-compliant, and the official CD will have more programs
on it than previously.

A few binary-only programs, etc. that are currently in "contrib" have
to be moved to "non-free". "contrib" packages will be allowed to
depend on non-free packages or packages that are entirely outside of
our archive. This means that there will be programs in "contrib" that
can not be installed if you don't have "non-free". For example, we
will distribute KDE in "contrib", and Qt in "non-free" (KDE depends on
Qt).

Here is the new policy text, which will be included in the next Debian
Policy Manual, version 2.3.0.0 (available soon):

   1. The main section

   Every package in "main" must comply with the DFSG.
   (The DFSG is Debian GNU/Linux's definition of "free" software.)

   In addition, the packages in "main"

      - must not require a package outside of "main" for compilation or
        execution (thus, the package may not declare a "Depends" or
        "Recommends" relationship on a non-main package),

      - must not be so buggy that we refuse to support them,

      - must meet all policy requirements presented in this manual.

   2. The contrib section

   Every package in "contrib" must comply with the DFSG.

   Examples of packages which would be included in "contrib" are

      - free packages which require "contrib", "non-free", or "non-US"
        packages or packages which are not in our archive at all for
        compilation or execution,

      - wrapper packages or other sorts of free accessories for
        non-free programs,

      - packages which we don't want to support because they are too
        buggy, and

      - packages which fail to meet some other policy requirements in
        a serious way.

   3. The non-free section

   "Non-free" contains packages which are not compliant with the DFSG
   or which are encumbered by patents or other legal issues that make
   their distribution problematic.

   All packages in "non-free" must be electronically distributable across
   international borders.

   4. The non-US section

   Some programs with cryptographic program code must be stored on the
   "non-us" server because of export restrictions of the U.S.

   This applies only to packages which contain cryptographic code. A package
   containing a program with an interface to a cryptographic program or a
   program that's dynamically linked against a cryptographic library can be
   distributed if it is capable of running without the cryptography library
   or program.

   5. Further copyright considerations

   Every package must be accompanied by a verbatim copy of its copyright
   and distribution license in the file
   /usr/doc/<package-name>/copyright.  This file may not be compressed
   and may not be a symbolic link.

   /usr/doc/<package-name> may be a symbolic link to a directory in
   /usr/doc only if two packages both come from the same source and the
   first package has a "Depends" relationship on the second. These rules
   are important because copyrights must be extractable by mechanical
   means.

   Packages distributed under the UCB BSD license, the Artistic license,
   the GNU GPL, and the GNU LPGL should refer to the files
   /usr/doc/copyright/BSD, /usr/doc/copyright/Artistic,
   /usr/doc/copyright/GPL, and /usr/doc/copyright/LGPL.

   In addition, the copyright file must say where the upstream sources
   (if any) were obtained, and explain briefly what modifications were
   made in the Debian version of the package compared to the upstream
   one. It must name the original authors of the package and the Debian
   maintainer(s) who were involved with its creation.

   We reserve the right to restrict files from being included anywhere in
   our archives if

      - their use or distribution would break a law,

      - there is an ethical conflict in their distribution or use,

      - we would have to sign a license for them, or

      - their distribution would conflict with other project policies.

- ----------------------------------------------------------------------------

Topic 2: netbase's configuration files

STATE: APPROVAL
INFO:  Peter Tobias asked me to add something like the text below
to the policy manual.

     4.2 Daemons

     The configuration files /etc/services, /etc/protocols, and
     /etc/rpc are managed by the netbase package and may not be
     modified by other packages.

     If a package requires a new entry in one of these files, the
     maintainer has to get in contact with the netbase maintainer, who
     will add the entries and release a new version of the netbase
     package.

     The configuration file /etc/inetd.conf may be modified by the
     package's scripts only via the update-inetd script or the
     DebianNet.pm Perl module.

     If a package wants to install an example entry into
     /etc/inetd.conf, the entry has to be preceded with exactly one
     hash character (#). Such lines are treated as `commented out by
     user' by the update-inetd script and are not changed or activated
     during a package updates.

- ----------------------------------------------------------------------------

Topic 3: tcl/tk virtual packages

STATE: APPROVAL

The AUTHORITATIVE LIST OF VIRTUAL PACKAGE NAMES (Jul 13) lists:

tcl-interpreter         Anything that provides /usr/bin/tclsh
tk-interpreter          Anything that provides /usr/bin/wish

However, it has been suggested to change these names into `tclsh' and
`wish', respectively, since the current names are inaccurate (`wish' is not
an `interpreter' since `tk' is not a language).

If there no objections, I'll change the names in the next release of the
policy manual (virtual package name list).

- ----------------------------------------------------------------------------

Topic 4: policy for MTA's file locking

STATE: APPROVAL
INFO:  Miquel built a liblockfile package which implements a NFS-safe
locking mechanism based on the results of the discussion on debian-devel
some time ago. (The packages are currently available at
ftp://ftp.cistron.nl/pub/people/miquels/lock/
and will be uploaded to master soon.)

     4.5 Mail transport agents

     All Debian mail-user-agents (MUAs) and mail-transport-agents
     (MTAs) have to use the maillock and mailunlock functions provided
     by the liblockfile packages to lock and unlock the mail boxes.
     These functions implement a NFS-safe locking mechanism.

- ----------------------------------------------------------------------------

Topic 5: perl module policy

STATE: APPROVAL

Naming conventions for packages containing Perl modules

Packages containing Perl modules have to carry the name of the topmost Perl
module they include: a package which contains the Perl modules "Foo" and
"Foo::Bar" must be called libfoo-perl.

If only the module "Foo::Bar" is included, the package must be called
libfoo-bar-perl.

If a perl module package is large (greater than 200k) and contains
architecture dependent code (Perl "XS" files) the architecture dependent
code must be put into another package. This package is called like the other
package, but with `-xs' at the end (for example, libfoo-perl-xs).

- ----------------------------------------------------------------------------

Topic 6: configuration files

STATE: APPROVAL
INFO:  We ran into several problems in the past when a package
tried to modify a configuration file of another package. That's why
we have to forbid a package to modify another package's conffiles.

     3.3.7 Configuration files

     [old text snipped]
     Only packages that are tagged conflicting with each other may
     specify the same file as conffile. A package may not modify a
     configuration file of another package.

     If two or more packages use the same configuration file, one of
     these packages has to be defined as owner of the configuration
     file, i.e. it has to list the file as conffile and has to provide
     a program that modifies the configuration file.

     The other packages have to depend on the owner package and use
     that program to update the configuration file.

     Sometimes it's appropriate to build a new package, which just
     provides the basic infrastructure for the other packages and which
     manages the shared configuration files. (Check out the sgml-base
     package as an example.)

- ----------------------------------------------------------------------------

Topic 7: UUCP-locking of devices

STATE: INPUT
REF:   cf. bug #11094 and #10575

As described in bug reports #11094 and #10575, we need to define a policy
for device locking.

Since UUCP locks are the default way to implement device locks (right?) we
should implement that.

Here is John Goerzen's description of UUCP locks:

     On Debian, UUCP lockfiles are stored in /var/lock. They are named
     "LCK..devicename"... So, for instance, a lockfile for /dev/ttyS1
     would be:

       /var/lock/LCK..ttyS1

     In the lockfile, there is the pid of the locking process,
     prepended by spaces so that the lockfile is exactly 11 bytes long
     (10 bytes for spaces and PID plus a LF). When the program is
     finished with the port, it should remove this file.

     If the file exists, and the PID in it referrs to a running
     program, gpm (or any other program) should assume that the line is
     in use and not attempt to use it.

     If the file exists but the PID in it is not valid, gpm should
     remove the existing file and create its own. (The previous locker
     probably died unexpectedly).

     If the file does not exist, gpm can assume that it is not in use
     and create its own lockfile.

     For an example of this behavior, one can look at minicom, uucp, or
     pppd (with locking enabled) to see how these programs accomplish
     it. (Of course, these are just examples; all serial comm programs
     like kermit, mgetty, seyon, etc. lock the port like this.)

But there is one yet-unresolved side effect: how can `device sharing' be
implemented with UUCP locks? For example, X Windows and gpm can use the same
mouse device at the same time. If one process would like the device, the
other does not have access.

Does someone have a hint how to solve this problem?

- ----------------------------------------------------------------------------

Topic 8: documentation policy

STATE: INPUT
INFO:  [I'll prepare the necessary changes to the policy and present
           them here, soon.]
REF:   cf. #7890, cf. #11095

- ----------------------------------------------------------------------------

Topic 9: starting daemons in the postinst scripts

STATE: INPUT

Some people suggested to implement the following policy:

     If a package installs a `daemon' that is usually started via an
     /etc/init.d/ script, the package should query the sysadmin after
     the installation (via the postinst script) if he/she wants to
     start the daemon now.

(Does someone know a better wording for this?)

- ----------------------------------------------------------------------------

Topic 10: usage of `must' and `should' in the manual

STATE: INPUT

Some people said that we should (or must? :-) change `should' into `must' in
the Policy Manual in most places, even if exceptions are allowed, since the
RFC's use this wording and some people might get confused, otherwise. Any
objections?

- ----------------------------------------------------------------------------

Topic 11: Pristine sources

STATE: DISCUSSION

Santiago Vila Doncel <sanvila@unex.es> suggested:

     Now that dpkg supports pristine sources, it could be made "official
     policy", for example: "From now on, each time a Debian package is
     upgraded upstream, the Debian source will try to be a well-behaved
     orig source, i.e. one that uncompresses in a directory named

     <package>-<upstream-version>

     (To avoid wasting space in master.debian.org, this will not be
     considered as a bug for packages based on current sources)."

This sounds quite reasonable to me. What do the others think?

- ----------------------------------------------------------------------------

Topic 12: where to install non-english docs

STATE: DISCUSSION

There was a discussion about this topic on debian-devel around Nov 96, but
without any decision (AFAIK).

Currently most packages with non-english docs install the files in
/usr/doc/LANG/<locale>

However, when people are looking for documentation for a specific program,
they'll probably look at /usr/doc/<pkg> first. Thus, wouldn't it be better
to install files into /usr/doc/<pkg>/<locale> ?

This would get us the following filesystem structure:

   /usr/doc/HOWTO/*-HOWTO.gz
   /usr/doc/HOWTO/de/*-HOWTO.gz
   /usr/doc/HOWTO/fr/*-HOWTO.gz
   ...
   /usr/doc/dpkg/dpkg-users-guide-to-be-written.ps
   /usr/doc/dpkg/de/german-translation.ps
   /usr/doc/dpkg/fr/french-translation.ps
   ...

Next question: Which language code should we use? In /usr/share/locale, for
example, we use <language>_<territory>.

The long version is necessary if files are accessed automatically. But I
using <language> only is enough for the /usr/doc/<pkg>/ directories, since
these files are accessed "by hand". If there would be different documents
for different territories, we could use <language>_<territory> just in these
(rare) cases.

Any comments?

- ----------------------------------------------------------------------------

Topic 13: secure admin scripts

STATE: DISCUSSION
INFO:  This topic is currently under discussion on debian-policy.

The following policy change is currently planned:

     Any scripts which create files in world-writable directories (i.e.
     in /tmp) have to use a mechanism which will fail if a file with
     the same name already exists.

     The Debian base distribution provides the `tempfile' utility for
     use by scripts for this purpose.

- ----------------------------------------------------------------------------

Topic 14: X Window Manager policy

STATE: DISCUSSION

Joey Hess wrote on Mon, 30 Jun 1997 to debian-devel:

     I maintain KDE, which includes a window manager, and I've been wondering how
     other window managers handle registering themselves in
     /etc/X11/window-managers. So I took a look at all th window managers.

     Some window managers add themselves to the top of the file, so they become the
     default window manager. Others add themselves to the bottom of the file, so
     the sysadmin doesn't get a chance to use them as a default window manager
     without editing the file. And many window managers don't add themselves to the
     file at all.

     Here's a survey I did:

     window manager    adds itself to /etc/X11/window-managers how
     --------------    -------------------------------------------
     kde               adds to bottom
     afterstep         adds to bottom
     fvwm              doesn't do so
     fvwm2             doesn't seem to do so (complex postinst, I just grepped it
     :-)
     fvwm95            adds to top
     gwm               doesn't do so
     9wm               doesn't do so
     ctwm              doesn't do so
     wm2               doesn't do so
     wmaker            doesn't do so
     olvwm             if olvwm entry not already present, prompt to make
                       default window manager or not, insert line in appropriate
                       place.

     I think olvwm's behavior is the best of the lot, since it gives the sysadmin
     a choice (and only asks once, not during upgrades, which is also very good
     behavior). I wonder if it'd be a good idea for one of the X packages to
     include a register-window-manager script that could be called from the
     postinst's to handle this, so all window managers functioned exactly alike?

Linh Dang suggested:

     Why not make /etc/X11/window-managers a directory which contains scripts for
     windows managers. Change /etc/X11/Xsession to start
     /etc/X11/window-managers/default (which is a symlink). A fvwm script should
     looks like:

     #!/bin/sh
     exec fvwm -F /etc/X11/fvwm/system.fvwmrc

I'd prefer Joey's solution: xbase should install a script `install-wm' (or
similar) which is called by all window manager's postinst scripts. The
`install-wm' script will ask the sysadmin where to place the new wm (top or
bottom of the file).

Any other ideas?

- ----------------------------------------------------------------------------

- --                  Christian Schwarz
                     schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian is looking     schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
for a logo! Have a
look at our drafts     PGP-fp: 8F 61 EB 6D CF 23 CA D7  34 05 14 5C C8 DC 22 BA
at    http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: latin1

iQCVAwUBM/hu7E4c72jvRVaFAQErwAP+NIF5lYuLUnNTpBJ3gj1qpxskNHiryvG1
2jJ9QT7D2ivxhi/WsOCY9FzHD19OKRseCGU7Z0TV9cla3Kl3kfXZqN2CRniXeBV9
x3ezL/1J0B3l4JLikAIymPmS+W0tdYCUzPg8LZJ7KeIl61qxQlnIu9zoPuovfNQP
cDHzmorwaoo=
=dd4/
-----END PGP SIGNATURE-----


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org . 
Trouble?  e-mail to templin@bucknell.edu .


Reply to: