- Date: Sun, 5 Nov 2017 19:08:06 +0100
- From: Sven Hartge <sven@xxxxxxxxxxxxx>
- Subject: Re: Rsync
Fred Ringwald <fred@xxxxxxxxxxxx> wrote:
> Yesterday Sven Hartge responded to my query regarding rsync, quoted
> However, my question was not a technical question asking why rsync was
> not automatically installed during a stock amd64 debian installation,
> but a more philosophical question as to why the debian administrators
> chose to make rsync optional, given the importance of backup data.
This is defined by the debian Policy
https://www.debian.org/doc/debian-policy/. For your question "3.7 Base
system", "3.8 Essential packages" and "2.5 Priorities" are relevant:
| 3.7. Base system
| The base system is a minimum subset of the Debian system that is
| installed before everything else on a new system. Only very few packages
| are allowed to form part of the base system, in order to keep the
| required disk usage very small.
| The base system consists of all those packages with priority required or
| important. Many of them will be tagged essential (see below).
| 3.8. Essential packages
| Essential is defined as the minimal set of functionality that must be
| available and usable on the system at all times, even when packages are
| in the “Unpacked” state. Packages are tagged essential for a system
| using the Essential control field. The format of the Essential control
| field is described in Essential.
| Since these packages cannot be easily removed (one has to specify an
| extra force option to dpkg to do so), this flag must not be used unless
| absolutely necessary. A shared library package must not be tagged
| essential; dependencies will prevent its premature removal, and we need
| to be able to remove it when it has been superseded.
| Since dpkg will not prevent upgrading of other packages while an
| essential package is in an unconfigured state, all essential packages
| must supply all of their core functionality even when unconfigured. If
| the package cannot satisfy this requirement it must not be tagged as
| essential, and any packages depending on this package must instead have
| explicit dependency fields as appropriate.
| Maintainers should take great care in adding any programs, interfaces,
| or functionality to essential packages. Packages may assume that
| functionality provided by essential packages is always available without
| declaring explicit dependencies, which means that removing functionality
| from the Essential set is very difficult and is almost never done. Any
| capability added to an essential package therefore creates an obligation
| to support that capability as part of the Essential set in perpetuity.
| You must not tag any packages essential before this has been discussed
| on the debian-devel mailing list and a consensus about doing that has
| been reached.
With that definition: No, rsync is not an essential part of a minimal
Now on to "2.5 Priorities":
| 2.5. Priorities
| Each package must have a priority value, which is set in the metadata
| for the Debian archive and is also included in the package’s control
| files (see Priority). This information is used to control which packages
| are included in standard or minimal Debian installations.
| Most Debian packages will have a priority of optional. Priority levels
| other than optional are only used for packages that should be included
| by default in a standard installation of Debian.
| The priority of a package is determined solely by the functionality it
| provides directly to the user. The priority of a package should not be
| increased merely because another higher-priority package depends on it;
| instead, the tools used to construct Debian installations will correctly
| handle package dependencies. In particular, this means that C-like
| libraries will almost never have a priority above optional, since they
| do not provide functionality directly to users. However, as an
| exception, the maintainers of Debian installers may request an increase
| of the priority of a package to resolve installation issues and ensure
| that the correct set of packages is included in a standard or minimal
| The following priority levels are recognized by the Debian package
| management tools.
| Packages which are necessary for the proper functioning of the system
| (usually, this means that dpkg functionality depends on these packages).
| Removing a required package may cause your system to become totally
| broken and you may not even be able to use dpkg to put things back, so
| only do so if you know what you are doing.
| Systems with only the required packages installed have at least enough
| functionality for the sysadmin to boot the system and install more
| Important programs, including those which one would expect to find on
| any Unix-like system. If the expectation is that an experienced Unix
| person who found it missing would say “What on earth is going on, where
| is foo?”, it must be an important package.  Other packages without
| which the system will not run well or be usable must also have priority
| important. This does not include Emacs, the X Window System, TeX or any
| other large applications. The important packages are just a bare minimum
| of commonly-expected and necessary tools.
| These packages provide a reasonably small but not too limited
| character-mode system. This is what will be installed by default if the
| user doesn’t select anything else. It doesn’t include many large
| No two packages that both have a priority of standard or higher may
| conflict with each other.
| This is the default priority for the majority of the archive. Unless a
| package should be installed by default on standard Debian systems, it
| should have a priority of optional. Packages with a priority of optional
| may conflict with each other.
| This priority is deprecated. Use the optional priority instead. This
| priority should be treated as equivalent to optional.
| The extra priority was previously used for packages that conflicted with
| other packages and packages that were only likely to be useful to people
| with specialized requirements. However, this distinction was somewhat
| arbitrary, not consistently followed, and not useful enough to warrant
| the maintenance effort.
|  The Debian archive software uses the term “component” internally
| and in the Release file format to refer to the division of an archive.
| The Debian Social Contract simply refers to “areas.” This document uses
| terminology similar to the Social Contract.
|  See What Does Free Mean? for more about what we mean by free
|  Debian’s FTP Masters publish a REJECT-FAQ which details the
| project’s current working interpretation of the DFSG.
|  It is possible that there are policy requirements which the
| package is unable to meet, for example, if the source is unavailable.
| These situations will need to be handled on a case-by-case basis.
|  This is an important criterion because we are trying to produce,
| amongst other things, a free Unix.
Now, is rsync required for the proper functioning of the system? No.
Is it important? No, it is not inside the bare minimum of
commonly-expected and necessary tools.
Is it standard? Debatably. rsync would be installed by default if it
was. But does everybody *need* rsync? No.
Thus the package is optional.
You say: "given the importance of backup data". OK, but is rsync the
*only* way to backup data? I for example use Bacula and Borg to secure
my data, I have no need for rsync. Why should it be installed on every
system if only users really using it need it.
This is why most packages are "Priority: optional", so they only get
installed if needed.
Sigmentation fault. Core dumped.