dpkg (1.1.4); priority=MEDIUM

  * Allow overwriting of conflicting packages being removed.  (Bug#2614.)

  * a.out control file says Pre-Depends: libc4 | libc.  (Bug#2640.)
  * ELF control file and libc dependencies changed to use finalised scheme.
  * ELF control file and libc dependencies for i386 only.  (Bug#2617.)

  * Guidelines say use only released libraries and compilers.
  * Install wishlist as /usr/doc/dpkg/WISHLIST.
  * Remove spurious entries for Guidelines in info dir file.

  * dpkg-deb --build checks permissions on control (DEBIAN) directory.

  * Spaces in control file fields not copied by dpkg-split.  (Bug#2633.)
  * Spaces in split file part control data ignore.  (Bug#2633.)

  * Portability fixes, including patch from Richard Kettlewell.
  * Fixed minor configure.in bug causing mangled GCC -W options.

 -- Ian Jackson <ian@chiark.chu.cam.ac.uk>  Thu, 4 Apr 1996 01:58:40 +0100

1 files changed, 744 insertions, 0 deletions

diff --git a/doc/guidelines.info-2 b/doc/guidelines.info-2
new file mode 100644
index 000000000..8018f09fc
--- /dev/null
+++ b/doc/guidelines.info-2
@@ -0,0 +1,744 @@
+This is Info file guidelines.info, produced by Makeinfo-1.63 from the
+input file ./guidelines.texi.
+
+START-INFO-DIR-ENTRY
+* Guidelines: (guidelines).       How to make Debian packages.
+END-INFO-DIR-ENTRY
+
+
+File: guidelines.info,  Node: configuration files - /etc/skel vs /usr/doc/examples,  Next: How to write the Description control file field,  Prev: Appendix,  Up: Appendix
+
+configuration files - /etc/skel vs /usr/doc/examples
+====================================================
+
+   There seems to be a certain amount of confusion about `/etc/skel'
+and `/usr/doc/examples'. The most important thing to remember is the
+following:
+
+   Files in `/etc/skel' will *automatically* be copied into *new* user
+accounts by `adduser'.  They should not be referenced there by any
+program. Files in `/usr/doc/examples' should not be installed
+automatically.
+
+   Therefore, if the program in question need a dotfile to exist in
+advance in `$HOME' to work *sensibly* that dotfile should be installed
+in `/etc/skel' (and listed in conffiles; *note conffiles::.).
+
+   However, programs that require dotfiles in order to operate sensibly
+(dotfiles that they do not create themselves automatically, that is) are
+a bad thing, and that programs should be configured by the Debian
+default installation as close to normal as possible.
+
+   Therefore, if a program in a Debian package needs to be configured in
+some way in order to operate sensibly that configuration should be done
+in a site-wide global configuration file elsewhere in `/etc' (and that
+file should be listed in conffiles).  Only if the program doesn't
+support a site-wide default configuration should a default per-user file
+be placed in `/etc/skel' (and listed in conffiles; *note conffiles::.).
+
+   The idea is as follows:
+
+   The sysadmin should ideally not have to do any configuration other
+than that done (semi-)automatically by the postinst script.
+
+   However, if they wish to change their configuration themselves
+(because the configuration they want is beyond the scope of the
+autoconfiguration, or because the autoconfiguration doesn't exist yet,
+or because they just want to do it themselves for any reason) then
+`/usr/doc/examples' exists as *documentation* for their benefit.
+
+   The only time these files should be read are by the sysadmin using
+their favourite editor or pager, or *perhaps* (in very complex packages)
+by the postinst as a template to build on or modify.
+
+   `/etc/skel' is part of the *implementation* of this configuration.
+It contains the files that are copied into new user accounts.  It
+should probably be as empty as we can make it.
+
+   Examples:
+`.profile'
+     `/etc/skel' should not contain a `.profile' file.  Anything that
+     needs to be done there should be done in `/etc/profile'.  Anything
+     that should not go in `/etc/profile' (users can't avoid running
+     `/etc/profile') probably should not be in the default
+     configuration.  bash has generally good default behaviour.
+
+`.bash_logout'
+     Likewise, bash functions perfectly happily without a
+     `.bash_logout', so none should be provided, since anything in it is
+     a deviation from the sensible default behaviour.
+
+`.xsession'
+     `/etc/skel' should not contain a `.xsession'.  `xdm''s system-wide
+     startup file `/usr/lib/X11/xdm/Xsession' supports a system-wide
+     default user configuration (which should probably be
+     `/etc/X11/Xsession' or some such) which may be overridden by
+     `.xsession' in the user's home directory.  Therefore there is no
+     need for a `.xsession' to be installed by default and none should
+     be provided.
+
+     Instead, a sensible `/etc/X11/Xsession' should be provided, and if
+     desired this can be used as a template by users who wish to install
+     their own configuration, or alternatively a more comprehensive
+     example with much commented-out interesting stuff could be put in
+     `/usr/doc/examples'.
+
+     If the sysadmin wishes to change the system-wide default they
+     should probably do this by editing `/etc/X11/Xsession' rather than
+     creating the file in `/etc/skel', because the former will affect
+     all user accounts that haven't explicitly overridden things by
+     creating their own file while the latter will only affect new
+     accounts.
+
+     All the configuration necessary for a program to function should be
+     provided.  Therefore sysadmins will not need to go through
+     `/usr/doc/examples' while editing configuration files in `/etc'
+     except in extreme cases (like INN) where the configuration was too
+     difficult to do automatically.
+
+`site-wide defaults'
+     Site-wide defaults should not go in `/etc/skel'.  In the case of
+     twm, for example, the system-wide default should be in
+     `/etc/X11/system.twmrc'.  (The default location for this in X11R5,
+     btw, is in `/usr/lib/X11' somewhere, but we can't put it on `/usr'
+     because of CDROM distributions, etc - hence the FSSTND's mandate
+     to put configuration files in `/etc'.)
+
+`.twmrc'
+     There should be no `.twmrc' file in `/etc/skel'.  You can have one
+     in `/usr/doc/examples' if you *like*, but why bother if
+     `system.twmrc' is a good example (and indeed is the one the user is
+     using before they create their own)?
+
+`m4'
+     `/usr/doc/examples' isn't mainly for example *configuration
+     files*.  It's for any kind of example file distributed with a
+     package.  For example, GNU m4 comes with a whole pile of example
+     m4 macro scripts, which is exactly what `/usr/doc/examples' is for.
+
+   Summary
+
+   Files that should be installed in new user accounts should be in
+`/etc/skel', as that will ensure that they *are* installed in new user
+accounts!  However, we should try to avoid the need for this.
+
+   `/usr/doc/examples' is just what it says: documentation in the form
+of examples.  If a sysadmin is required to go and read these files for
+their system to work they should be told about it.  For example, here
+is what the Smail postinst script says right at the start:
+
+     I can do certain kinds of automatic configuration of your
+     mail system, by asking you a number of questions.  Later you
+     may to confirm and/or correct your answers.  In any case,
+     comprehensive information on configuring Smail is in
+     smail(5) and in /usr/doc/examples/smail and
+     /usr/doc/smail-admin-guide.
+
+
+File: guidelines.info,  Node: How to write the Description control file field,  Next: Configuration of init,  Prev: configuration files - /etc/skel vs /usr/doc/examples,  Up: Appendix
+
+How to write the Description control file field
+===============================================
+
+   The format of the `Description' field is as follows:
+
+     Description: <single line synopsis>
+      <extended description over several lines>
+
+   The extended description has several kinds of line:
+
+   * Those starting with a single space are part of a paragraph.
+     Successive lines of this form will be word-wrapped when displayed.
+     The leading space will usually be stripped off.
+
+   * Those starting with two or more spaces.  These will be displayed
+     verbatim.  If the display cannot be panned horizontally the
+     displaying program will linewrap them `hard' (ie, without taking
+     account of word breaks).  If it can they will be allowed to trail
+     off to the right.  None, one or two initial spaces may be deleted,
+     but the number of spaces deleted from each line will be the same
+     (so that you can have indenting work correctly, for example).
+
+   * Those containing a single space followed by a single full stop
+     character.  These are rendered as blank lines.  This is the *only*
+     way to get a blank line - see below.
+
+   * Those containing a space, a full stop and some more characters.
+     These are for future expansion.  *Do not* use them.
+
+   IMPORTANT and not so important TIPS:
+
+   * *Always* start extended description lines with at least *one*
+     whitespace character.  Fields in the control file and in the
+     Packages file are separated by field names starting in the first
+     column, just as in RFC822.  Forgetting the whitespace will cause
+     `dpkg-deb' (>=0.93.23) to produce a syntax error when trying to
+     build the package.  If you force it to build anyway `dpkg' will
+     refuse to install the resulting mess.
+
+   * *Do not* include any completely *empty* lines. These separate
+     different records in the Packages file, and are forbidden in
+     control files.  See the previous paragraph for what happens if you
+     get this wrong.
+
+   * The single line synopsis should be kept brief - certainly under 80
+     characters.  `dselect' displays the *first 49* characters if
+     you're using an 80-column terminal.
+
+   * Do not include the package name in the synopsis line.  The display
+     software knows how to display this already, and you do not need to
+     state it.  Remember that in many situations the user may only see
+     the synopsis line - make it as informative as you can.
+
+   * The extended description should describe what the package does and
+     how it relates to the rest of the system (in terms of, for
+     example, which subsystem it is which part of).
+
+   * Put important information first, both in the synopis and extended
+     description.  Sometimes only the first part of the synopsis or of
+     the description will be displayed.  You can assume that there will
+     usually be a way to see the whole extended description.
+
+   * You may include information about dependencies and so forth in the
+     extended description, if you wish.
+
+   * Do not use tab characters.  Their effect is not predictable.
+
+   Example control file for Smail:
+
+     Package: smail
+     Version: 3.1.29.1-13
+     Maintainer: Ian Jackson <iwj10@cus.cam.ac.uk>
+     Recommends: pine | mailx | elm | emacs | mail-user-agent
+     Suggests: metamail
+     Depends: cron, libc5
+     Conflicts: sendmail
+     Provides: mail-transport-agent
+     Description: Electronic mail transport system.
+      Smail is the recommended mail transport agent (MTA) for Debian.
+      .
+      An MTA is the innards of the mail system - it takes messages from
+      user-friendly mailer programs and arranges for them to be delivered
+      locally or passed on to other systems as required.
+      .
+      In order to make use of it you must have one or more user level
+      mailreader programs such as elm, pine, mailx or Emacs (which has Rmail
+      and VM as mailreaders) installed.  If you wish to send messages other
+      than just to other users of your system you must also have appropriate
+      networking support, in the form of IP or UUCP.
+
+
+File: guidelines.info,  Node: Configuration of init,  Next: Maintainer script arguments and how `dpkg' does things,  Prev: How to write the Description control file field,  Up: Appendix
+
+Configuration of init
+=====================
+
+   The `/etc/init.d' directory contains the scripts executed by init(8)
+when init state (or "runlevel") is changed.  This includes the boot
+process, when the multi-user state begins.  Several of these scripts
+are included with init and are intended to be executed *once*, usually
+at boot time.  An example is `/etc/init.d/boot', which is executed at
+boot time to check and mount file systems, activate swap, load kernel
+modules, etc.-everything that needs to be done before the multi-user
+state begins.  `/etc/init.d' also contains the scripts that are
+executed when entering runlevel 0 (halt), runlevel 1 (single-user) and
+runlevel 6 (reboot).
+
+   Packages can (and should) place scripts in `/etc/init.d' to start or
+stop services at boot time or during a change of runlevel.  These
+scripts should be named `/etc/init.d/'<package>, and they should accept
+one of two arguments: "start", which starts the services, or "stop",
+which stops the services.  These scripts should ensure that they will
+behave sensibly if invoked with "start" when the service is already
+running, or with "stop2 when it isn't--the best way to achieve this is
+often to use `start-stop-daemon'.
+
+   This script should not fail obscurely when the configuration files
+remain but the package has been removed, as the default in dpkg is to
+leave configuration files on the system after the package has been
+removed.  Only when it is executed with the `-purge' option will dpkg
+remove configuration files.  Therefore, you should include a `test'
+statement at the top of the script, like this:
+
+     test -f <program-executed-later-in-script> || exit 0
+
+   These scripts should be referenced, when appropriate, by symbolic
+links in the `/etc/rc?.d' directories, as below.
+
+   When changing runlevels, init looks in the directory `/etc/rc<n>.d'
+for the scripts it should execute, where <n> is the runlevel that is
+being changed to.  Please note that the "scripts" in `/etc/rc?.d' are
+not actually scripts; they are symbolic links, referencing actual
+scripts in `/etc/init.d'.  For simplicity, we refer to them as
+"scripts".
+
+   First, the scripts prefixed with a "K" are executed, followed by the
+scripts prefixed with an "S".  The "K" scripts are responsible for
+killing certain services and the "S" scripts for starting certain
+services upon *entering* the runlevel.  For example, if we are changing
+from runlevel 2 to runlevel 3, init will first execute all of the "K"
+prefixed scripts it finds in `/etc/rc3.d' (to kill services), and then
+all of the "S" prefixed scripts it finds in `/etc/rc3.d' (to start
+services).  The "K" scripts will execute the file it references with an
+argument of "stop", and the "S" scripts will execute this file with an
+argument of "start".
+
+   After the "K" or "S" prefix, there should be a number specified, and
+this number should be between 00 and 99.  The number determines the
+order in which the scripts are run.  For example, the "K20" scripts will
+be executed before the "K30" scripts.  You can use this number to make
+sure that a certain service is started before another.  For example, on
+some machines, the program `setserial' may need to properly set an IRQ
+before the `ppp' program uses a modem to connect to a network.  In this
+case, the script that runs `setserial' should have a lower number than
+the script that starts `ppp' so that it runs first:
+
+     `/etc/rc2.d/S10setserial'
+     `/etc/rc2.d/S20ppp'
+
+   If it does not matter when or in which order the script is run, use
+the number "20".  If it does, then you should talk to the maintainer of
+the `sysvinit' package or post to `debian-devel', and they will help
+you choose a number.
+
+   In Debian GNU/Linux, we try to ship our software in as much of a
+"default" state as possible.  Therefore, unless there is a good reason
+for doing differently, we ask that you start and stop the services in
+each of the multi-user state runlevels (2, 3, 4, and 5).  If a service
+needs to be stopped before a file system can be unmounted (an example is
+process accounting or quota services), then be sure to stop them in the
+halt runlevel (0), the single-user runlevel (1) and the reboot runlevel
+(6).
+
+   The system administrator will have the opportunity to customize
+runlevels by simply adding, moving, or removing the symbolic links in
+`/etc/rc?.d'.  This is why we default to running everything in the
+multi-user state-a reasonable default-and the administrator can easily
+customize init to be as complex and sophisticated as he or she wants it
+to be beyond this.
+
+   We provide a script, `update-rc.d', to make it easier for package
+maintainers to arrange for the proper creation and removal of
+`/etc/rc?.d' symbolic links from their postinst and postrm scripts.
+You should use this script to make changes to `/etc/rc?.d' and *never*
+include any `/etc/rc.?.d' symbolic links in the actual archive.
+
+   * In the postinst script, you need only do the following to setup
+     `/etc/rc?.d'.  You should redirect standard output to `/dev/null',
+     as `update-rc.d' produces insignificant output:
+
+          update-rc.d <package> default >/dev/null
+
+     where <package> is the name of the file as it appears in
+     `/etc/init.d'.  It will use the default number of "20", as
+     mentioned above.  If you need to use a different number, you can
+     specify it after "default":
+
+          update-rc.d <package> default 30 >/dev/null
+
+   * In the postrm script, you need only do the following *if and only
+     if* it is called with the `purge' argument:
+
+          if [ purge = "$1" ]
+          then
+            update-rc.d <package> remove >/dev/null
+          fi
+
+Important Note:
+---------------
+
+   *Do not* include the `/etc/rc?.d/*' symbolic links in the archive!
+*This will cause problems!*  You should create them with update-rc.d,
+as above.
+
+   *Do not* include the `/etc/rc?.d/*' symbolic links in conffiles!
+*This will cause problems!*  *Do*, however, include the `/etc/init.d'
+scripts in conffiles.
+
+Example:
+--------
+
+   The process accounting package wants to make sure that process
+accounting is started at boot time and that it is stopped before the
+system is halted, enters the single-user state, or is rebooted (so that
+the `/var' file system can be properly unmounted).  It puts a script
+that does this in `/etc/init.d', naming the script appropriately
+"acct".  This script accepts one of two arguments: either "start",
+which starts process accounting, or "stop", which stops it.  To ensure
+that it does not fail obscurely when the configuration files remain but
+the package has been removed, we include a `test' statement at the top
+of the script:
+
+     #! /bin/sh
+     #
+     # Start process accounting.
+     . /etc/init.d/functions
+     test -f /usr/sbin/accton || exit 0
+     case "$1" in
+       start)
+         echo "Starting process accounting"
+         /usr/sbin/accton /var/account/pacct
+         ;;
+       stop)
+         echo "Stopping process accounting"
+         /usr/sbin/accton
+         ;;
+       *)
+         echo "Usage: /etc/init.d/acct {start|stop}"
+         exit 1
+     esac
+     exit 0
+
+   You may find a skeletal script from which to base your `/etc/init.d'
+scripts in `/etc/init.d/skeleton'.
+
+   We want to stop then (re)start process accounting when entering a
+multi-user state-runlevels 2, 3, 4, and 5-and we want to stop it when
+leaving such a state-runlevels 0 (halt), 1 (single) and 6 (reboot).
+These are good defaults, and we accomplish this by including the
+following in the postinst:
+
+     update-rc.d acct default >/dev/null
+
+   When the user removes the acct packages with the `-purge' option, we
+want to make sure the `/etc/rc?.d' symbolic links are properly removed,
+so we include the following in the postrm:
+
+     update-rc.d acct remove >/dev/null
+
+   Otherwise, the `/etc/rc?.d' symbolic links will remain on the system
+along with `/etc/init.d/acct' script.
+
+
+File: guidelines.info,  Node: Maintainer script arguments and how `dpkg' does things,  Next: Mail processing packages,  Prev: Configuration of init,  Up: Appendix
+
+Maintainer script arguments and how `dpkg' does things
+======================================================
+
+   This appendix describes exactly how maintainer scripts are called,
+with what arguments, in what order, and what `dpkg' does in between.
+
+   In all cases version numbers are <version>-<revision>, if the package
+has both, or just <version>.  `upgrade' is used even when the new
+version number looks lower than the old.
+
+Summary
+-------
+
+     <new preinst> install
+     <new preinst> install <old-version>
+     <new preinst> upgrade <old-version>
+     <old preinst> abort-upgrade <new-version>
+     
+     <postinst> configure
+     <old postinst> abort-upgrade <new version>
+     <conflictor's postinst> abort-remove in-favour <package> <new version>
+     <deconfigured's postinst> abort-deconfigure \
+                   in-favour <package-being-installed-but-failed> <version>
+                   removing <conflicting-package> <version>
+     
+     <prerm> remove
+     <old prerm> upgrade <new version>
+     <new prerm> failed-upgrade <old-vppersion>
+     <conflictor's prerm> remove in-favour <package> <new version>
+     <deconfigured's prerm> deconfigure \
+                   in-favour <package-being-installed> <version> \
+                   removing <conflicting-package> <version>
+     
+     <postrm> remove
+     <postrm> purge
+     <old postrm> upgrade <new-version>
+     <new postrm> failed-upgrade <old-version>
+     <new postrm> abort-install
+     <new postrm> abort-install <old-version>
+     <new postrm> abort-upgrade <old-version>
+     <disappearer's postrm> disappear <overwriter> <new version>
+
+Details of unpack phase of installation or upgrade
+--------------------------------------------------
+
+   The procedure on installation/upgrade/overwrite/disappear (ie, when
+running `dpkg --unpack', or the unpack stage of `dpkg --install') is as
+follows.  In each case if an error occurs the actions in are general
+run backwards - this means that the maintainer scripts are run with
+different arguments in reverse order.  These are the `error unwind'
+calls listed below.
+
+  1.
+       a. If a version the package is already installed, call
+               <old prerm> upgrade <new version>
+
+       b. If this gives an error (ie, a non-zero exit status), dpkg will
+          attempt instead:
+               <new prerm> failed-upgrade <old-version>
+           error unwind, for both the above cases:
+               <old postinst> abort-upgrade <new version>
+
+  2. If a `conflicting' package is being removed at the same time:
+       a. If any packages depended on that conflicting package and
+          `--auto-deconfigure' is specified, call, for each such
+          package:
+               <deconfigured's prerm> deconfigure \
+                in-favour <package-being-installed> <version> \
+                removing <conflicting-package> <version>
+           error unwind:
+               <deconfigured's postinst> abort-deconfigure \
+                in-favour <package-being-installed-but-failed> <version>
+                removing <conflicting-package> <version>
+          The deconfigured packages are marked as requiring
+          configuration, so that if -install is used they will be
+          configured again if possible.
+
+       b. To prepare for removal of the conflicting package, call:
+               <conflictor's prerm> remove in-favour <package> <new version>
+           error unwind:
+               <conflictor's postinst> abort-remove in-favour <package> <new version>
+
+  3.
+       a. If the package is being upgraded, call
+               <new preinst> upgrade <old-version>
+
+       b. otherwise, if the package had some configuration files from a
+          previous version installed (ie, it is in the conffiles-only
+          state):
+               <new preinst> install <old-version>
+
+       c. otherwise (ie, the package was completely purged):
+               <new preinst> install
+           error unwind versions, respectively:
+               <new postrm> abort-upgrade <old-version>
+               <new postrm> abort-install <old-version>
+               <new postrm> abort-install
+
+  4. The new package's files are unpacked, overwriting any that may be
+     on the system already, for example any from the old package or
+     from another package (backups of the old files are left around,
+     and if anything goes wrong dpkg will attempt to put them back as
+     part of the error unwind).
+
+  5.
+       a. If the package is being upgraded, call
+               <old postrm> upgrade <new-version>
+
+       b. If this fails, dpkg will attempt:
+               <new postrm> failed-upgrade <old-version>
+           error unwind, for both cases:
+               <old preinst> abort-upgrade <new-version>
+          This is the point of no return - if dpkg gets this far, it
+     won't back off past this point if an error occurs.  This will
+     leave the package in a fairly bad state, which will require a
+     successful reinstallation to clear up, but it's when dpkg starts
+     doing things that are irreversible.
+
+  6. Any files which were in the old version of the package but not in
+     the new are removed.
+
+  7. The new file list replaces the old.
+
+  8. The new maintainer scripts replace the old.
+
+  9. Any packages all of whose files have been overwritten during the
+     installation, and which aren't required for dependencies, are
+     considered to have been removed.  For each such package,
+       a. dpkg calls:
+               <disappearer's postrm> disappear <overwriter> <new version>
+
+       b. The package's maintainer scripts are removed.
+
+       c. It is noted in the status database as being in a sane state,
+          namely not installed (any conffiles it may have are ignored).
+          Note that disappearing packages do not have their prerm
+          called, because dpkg doesn't know in advance that the package
+          is going to vanish.
+
+ 10. Any files in the package we're unpacking that are also listed in
+     the file lists of other packages are removed from those lists.
+     (This will lobotomise the file list of the `conflicting' package
+     if there is one.)
+
+ 11. The backup files made at 4. are deleted.
+
+ 12. The new package's status is now sane, and recorded as `unpacked'.
+     Here is another point of no return - if the conflicting package's
+     removal fails we do not unwind the rest of the installation; the
+     conflicting package is left in a half-removed limbo.
+
+ 13. If there was a conflicting package we go and do the removal
+     actions, starting from point 2. of the removal, below.
+
+Details of configuration
+------------------------
+
+   When we configure a package (this happens with `dpkg --install', or
+with `--configure'), we first update the conffiles and then call:
+     <postinst> configure <most-recently-configured-version>
+
+   No attempt is made to unwind after errors during configuration.
+
+Details of removal and/or configration purging
+----------------------------------------------
+
+  1.      <prerm> remove
+
+  2. The package's files are removed (except conffiles).
+
+  3.      <postrm> remove
+
+  4. All the maintainer scripts except the postrm are removed.
+
+     If we aren't purging the package we stop here.  Note that packages
+     which have no postrm and no conffiles are automatically purged
+     when removed, as there is no difference except for the dpkg status.
+
+  5. The conffiles and any backup files (`~'-files, `#*#' files,
+     `%'-files, .dpkg-{old,new,tmp}, etc.) are removed.
+
+  6.      <postrm> purge
+
+  7. The package's file list is removed.
+        No attempt is made to unwind after errors during removal.
+
+
+File: guidelines.info,  Node: Mail processing packages,  Next: Virtual dependencies,  Prev: Maintainer script arguments and how `dpkg' does things,  Up: Appendix
+
+Mail processing packages
+========================
+
+   Debian packages which process electronic mail (whether
+mail-user-agents (MUA) or alternative mail-transport-agents (MTA))
+*must* make sure that they are compatible with the configuration
+decisions below.  Failure to do this may result in lost mail, broken
+`From:' lines, and other serious brain damage!
+
+   * The mail spool is `/var/spool/mail' and the interface to send a
+     mail message is `/usr/sbin/sendmail' (as per the FSSTND).  The mail
+     spool is part of the base and not part of the MTA package.
+
+   * Mailboxes are locked using the `.lock' lockfile convention, rather
+     than fcntl, flock or lockf.
+
+   * Mailboxes are generally 660 `<user>.mail' unless the user has
+     chosen otherwise.  A MUA may remove a mailbox (unless it has
+     nonstandard permissions) in which case the MTA or another MUA must
+     recreate it if needed.  Mailboxes must be writeable by group mail.
+
+   * The mail spool is 2775 mail.mail, and MUA's need to be setgid mail
+     to do the locking mentioned above (and obviously need to avoid
+     accessing other users' mailboxes using this privilege).
+
+   * `/etc/aliases' is the source file for the system mail aliases (e.g.
+     postmaster, usenet, etc.) - it is the one which the sysadmin and
+     postinst scripts may edit.
+
+   * The convention of writing `forward to <address>' in the mailbox
+     itself is not supported.  Use a `.forward' file instead.
+
+   * The location for the `rmail' program used by UUCP for incoming mail
+     is `/usr/sbin/rmail', as per the FSSTND.  Likewise, `rsmtp', for
+     receiving batch-SMTP-over-UUCP, is in `/usr/sbin/rsmtp' if it is
+     supported.
+
+   * Smail is not using HoneyDanBer UUCP, whose uux apparently accepts
+     -a and -g options.
+
+   * If you need to know what name to use (for example) on outgoing
+     news and mail messages which are generated locally, you should use
+     the file `/etc/mailname'.  It will contain the portion after the
+     username and `@' sign for email addresses of users on the machine
+     (followed by a newline).
+
+   A package should check for the existence of this file.  If it exists
+it should use it without comment (1).  If it does not exist it should
+prompt the user for the value and store it in `/etc/mailname' as well
+as using it in the package's configuration.  The prompt should make it
+clear that the name will not just be used by that package.  E.g., in
+the same situation the INN package says:
+
+     Please enter the `mail name' of your system.  This is the hostname
+     portion of the address to be shown on outgoing news and mail messages.
+     The default is `$syshostname', your system's host name.
+     Mail name [`$syshostname']:
+   ($syshostname is the output of `hostname -fqdn').
+
+   ---------- Footnotes ----------
+
+   (1)  An MTA's prompting configuration script may wish to prompt the
+user even if it finds this file exists.
+
+
+File: guidelines.info,  Node: Virtual dependencies,  Prev: Mail processing packages,  Up: Appendix
+
+Virtual dependencies
+====================
+
+   Virtual packages are in the same namespace as real packages, and may
+have the same name.  The meaning of a virtual package in a
+dependency/conflicts list is exactly that of listing all the real
+packages which state that they are an instantiation of that virtual
+package.
+
+   This is done with a new Provides field in the control file, with a
+syntax much like the Conflicts field.
+
+   The idea is that we can have something like:
+     Package: elm
+     Depends: mta
+     
+     Package: smail
+     Provides: mta
+     Conflicts: mta
+     
+     Package: sendmail
+     Provides: mta
+     Conflicts: mta
+    The result is equivalent to elm having said
+     Package: elm
+     Depends: smail | sendmail
+
+   (There'll be a special case to say that a package may conflict with a
+virtual package which it provides - clearly ...)
+
+   If there are both a real and a virtual package of the same name then
+the dependency may be satisfied (or the conflict caused) by either the
+real package or any of the virtual packages which provide it.  This is
+so that, for example, supposing we have
+     Package: lout
+     Optional: ghostview
+   (this is a fictional example - the Lout package should not mention
+ghostview), and someone else comes up with a nice PostScript previewer,
+then they can just say
+     Package: marvelpostview
+     Provides: ghostview
+   and all will work in the interim (until, say, the Lout maintainer
+changes things).
+
+   If a dependency or a conflict has a version number attached then only
+real packages will be considered to see whether the relationship is
+satisfied (or prohibited, for a conflict) - it is assumed that a real
+package which provides virtual package is not of the `right' version.
+If there is demand it can be arranged that a package which provides a
+virtual package may mention a version number, though this is unlikely to
+be helpful:
+     Provides: mta (2.0)
+
+   If you want to specify which of a set of real packages should be the
+default to satisfy a particular dependency on a virtual package, you can
+simply list the real package as alternative before the virtual one:
+     Package: xbaseR6
+     Recommended: xsvga | x-server
+     Provides: x-base, xr6shlib
+     
+     Package: xsvga
+     Recommended: x-base
+     Provides: x-server
+     
+     Package: x8514
+     Recommended: x-base
+     Provides: x-server
+
+   Virtual package names should generally not be used in the names of
+`/etc/init.d' scripts, configuration files, logfiles, and so on, so
+that several programs providing the same virtual package name can be
+installed.
+
+