--- Begin Message ---
- To: 934948-done@bugs.debian.org
- Subject: Bug#934948: Dropping dependencies to avoid extra binary package when same source package targets more than one environment
- From: Simon McVittie <smcv@debian.org>
- Date: Wed, 18 Dec 2019 22:55:16 +0000
- Message-id: <20191218225516.GA257717@espresso.pseudorandom.co.uk>
- In-reply-to: <E3A39F90-8690-4AC5-9EFF-17E1F4CD9EA7@debian.org>
- References: <E3A39F90-8690-4AC5-9EFF-17E1F4CD9EA7@debian.org> <E3A39F90-8690-4AC5-9EFF-17E1F4CD9EA7@debian.org>
The technical committee has been asked to consider what level of binary
package granularity is appropriate for the src:ruby-task-list package,
and for similar packages that provide library code for more than one
language in the same upstream source release. This is advice under
§6.1(5) of the Debian constitution, and is not intended to overrule
any developers' decisions.
1. When there is disagreement about the level of splitting necessary
between binary and source packages, we encourage maintainers and the
ftp team to communicate respectfully, and in particular acknowledge
that each other's goals are valid, even if arguing that those goals
should be outweighed by higher-priority goals.
We also encourage maintainers to be as clear as possible about the
purpose and relationship of the various parts of a source package.
2. We suggest considering the following design principles. These are
principles, not hard rules, so it is likely to be necessary to
compromise on some of them where they conflict.
* We should not have very large numbers of very small binary packages.
- Justification: that results in the Packages file being very large,
creating overhead for all users.
* We should not have very large numbers of very small source packages.
- Justification: that requires maintainers and the ftp team to spend
a lot of time processing those source packages, and also results
in the Sources file being very large, creating overhead for all
developers.
* In general we do not want to "bundle" multiple independently-maintained
things into the same source package. However, if we understand
correctly, the ftp team have indicated that they are willing to
compromise on this (by bundling the dependencies of leaf packages
into the package that depends on them, or creating library packages
containing several related libraries) in order to avoid having a very
large number of very small source packages.
- Justification: when independently-maintained projects are bundled
into one omnibus package, it is necessary for its maintainer to
curate its contents and update the package when enough changes have
accumulated; the resulting package might be more difficult to maintain
because tools like uscan normally assume a single upstream.
* When a package is installed, installation must succeed: that is, its
dependencies must be sufficient to run the preinst and postinst scripts
(for example, if Python code in a package is to be byte-compiled during
installation, then the package's dependencies must be enough to carry
out byte-compilation successfully).
- Justification: merely installing a package should always succeed.
* When a package containing user-facing executable programs is installed,
those executables should normally work: that is, their dependencies
should usually be sufficient to run the executables.
- Exception: if the package collects multiple executables, it is OK for
less-critical executables (those outside the core functionality of
the package) to have additional dependencies that are only Recommends
or Suggests for the package. devscripts is a good example of this.
- Exception: executables in /usr/share/doc/*/examples may have
additional dependencies
* When a library is installed, it must be usable in the relevant
interpreter(s). That is, its dependencies, plus the interpreter itself,
must be sufficient to import and use the library.
* Libraries written in a language should generally not depend on that
language's interpreter. For example, chiark-tcl does not have a TCL
interpreter in its Depends, and we consider that to be valid, although
for some interpreters there may be other reasons why a dependency is
necessary (for example, Python libraries require the Python interpreter
for the byte-compile step).
- Justification: if you want to make use of a library (for example
chiark-tcl) in your program (for example sauce), you already have
to write the program in a compatible language, in which case you
already know you need the relevant interpreter. Also, some languages
are available to more than one interpreter simultaneously, for example
JavaScript code that can execute locally in nodejs, mozjs, seed etc.
or be served for execution by web browsers.
* When a user installs a library for one interpreter or environment,
in general, we don't want the package dependencies to require that
user to install an unrelated interpreter.
- Justification: this is a waste of space and network bandwidth,
and may increase the attack surface for that user's system.
* If the main purpose of a package is to provide a runtime library,
it should usually be packaged according to the relevant language's
library conventions (for example libflatpak0, libyaml-perl or
python3-tap).
* User-facing executable programs associated with a library should
usually be packaged in a non-library binary package whose name reflects
the program (for example tappy, flatpak, parted) or collection of
related programs (for example kmod, libsecret-tools, libglib2.0-bin),
rather than being bundled in the same binary package as the runtime
library.
- Justification: bundling programs in library packages causes
parallel-installation of different versions of a library to be more
difficult (see Policy §8.2), and makes it more difficult for users to
discover the programs' existence (for example it is far from obvious
that python-rgain contains CLI programs and not just a library).
* Executable programs that are used to develop with a library, but are not
user-facing (for example SDL's sdl2-config) do not require a separate
non-library binary package unless there are other reasons to do so (for
example multiarch), and the interpreters and other programs needed to
run them do not need to be direct dependencies if they would be part
of a normal development environment for the language (for example
the package containing sdl2-config does not need a dependency on a
C compiler).
3. For the specific case of src:ruby-task-list, which provides both a Ruby
library and a JavaScript library, we suggest:
* shipping both Ruby and JavaScript libraries in a single binary package
* removing the dependency on the Ruby interpreter, unless there is a
reason why it is required
* asking the maintainers of the Ruby libraries that ruby-task-list
recursively depends on (such as ruby-rack) to remove *their* dependencies
on the Ruby interpreter, unless there is a reason why it is required
--
smcv
for the Technical Committee
--- End Message ---