Bug#934948: Unnecessary dependencies vs multiple binary packages
On Sat, 17 Aug 2019 at 11:20:22 +0530, Pirate Praveen wrote:
> I'd like to bring to your notice a disagreement with ftp masters about adding
> multiple binary packages when the same source package has code targeting
> multiple environments.
While attempting to construct a summary of the situation and constraints
I realised you were talking about two separate situations, which are not
necessarily particularly similar. The correct answer might be different
in each case.
Please correct anything that I've got wrong here:
Background
==========
* When I say "library" below I mean the equivalent of libfoo.so.0 or
libyaml-perl: reusable code that can be imported into a program or another
library but is not directly executable in its own right.
* When I say "executable" below I mean the equivalent of
/usr/bin/dpkg-architecture: a script that is intended to be executed
directly.
* All correctly-packaged Ruby libraries have a dependency on the Ruby
interpreter, regardless of whether they also contain a #!/usr/bin/ruby
executable script. This is similar to what is done for Perl and Python.
- Please fact-check: is this true?
* Packages that contain an executable #!/usr/bin/ruby script in the PATH
or in some location from which it will be run as an executable (like
/usr/libexec) must have a dependency on the Ruby interpreter, otherwise
they cannot work, which would be a grave bug.
* Correctly-packaged node.js libraries (that do not also contain an
executable #!/usr/bin/nodejs script) *do not* normally have a dependency
on the node.js interpreter, unlike Ruby, Perl or Python.
- Please fact-check: is this true?
* Packages that contain a #!/usr/bin/nodejs script in the PATH or in some
location from which it will be run as an executable must have a
dependency on the node.js interpreter, otherwise they cannot work,
which would be a grave bug.
* Packages that contain a #!/usr/bin/nodejs or #!/usr/bin/ruby script in
/usr/share/doc/*/examples do not necessarily have a dependency on the
appropriate interpreter, because it's only an example.
* Some, but not all, JavaScript libraries are suitable for use in both
node.js and web browsers, similar to the way some, but not all, Python
code is suitable for both Python 2 and Python 3.
* Correctly-packaged libraries of JavaScript for use in web browsers
normally depend on javascript-common, but do not depend on an interpreter.
- Please fact-check: is this true?
ruby-task-list
==============
* The ruby-task-list source package contains (among other things)
a Ruby library, `task_list`, and a Node.JS library, `deckar01-task_list`.
* You want to put the Ruby library in the package dictated by Ruby policy,
ruby-task-list.deb, and the Node.JS library in the package dictated by
Node.JS policy, node-deckar01-task-list.deb.
- The ftp team objection to this is that both libraries are very small
(a few K each) so the resulting data:metadata ratio is unfavourable.
* The ftp team want you to combine those two into one binary package,
ruby-task-list.deb, and give it
Provides: node-deckar01-task-list (= ${binary:Version}).
- Your objection to this is that users who install the combined package
have to install Ruby, even if they only want the node.js library.
This is because it contains a Ruby library, and Ruby libraries have
Depends on the Ruby interpreter.
- You said that users who install the combined package would also have
to install node.js even if they only want the Ruby library, but I'm
not sure whether this is true? node-normalize.css, for example,
doesn't seem to have Depends on node.js?
node-autoprefixer
=================
* The node-autoprefixer source package contains a "pure Javascript" library
named `autoprefixer` that can be used from either node.js or any other
Javascript environment, including web browsers.
* It also contains a command-line executable `.../bin/autoprefixer` which
has #!/usr/bin/nodejs.
* As far as I can tell, the command-line executable `.../bin/autoprefixer`
is not in the PATH. I don't know whether it is run automatically in
some other way, analogous to a program in /usr/libexec.
- Please fact-check: is it in the PATH? Is it run as an executable
in some other way?
* You wanted to put a copy of the library and command-line executable in
a binary package named node-autoprefixer for use in the node.js
interpreter (which would have Depends: nodejs because of the executable),
and a second copy of the library for use in web browsers in a binary
package named libjs-autoprefixer (which would not have any particular
dependencies except javascript-common).
- The ftp team objection to this is that, again, both libraries are
rather small.
* The ftp team recommendation was to have a node-autoprefixer package with
Provides: libjs-autoprefixer (= ${binary:Version}).
- Your objection to this is that users who install the combined package
have to install node.js, even if they are only using the autoprefixer
library from a web browser.
Design principles
=================
(These are principles, not hard rules, so we might need to compromise on
some of them where they conflict.)
* The ftp team do not want to have very large numbers of very small binary
packages, because that results in the Packages file being very large,
creating overhead for all users.
* The ftp team do not want to have very large numbers of very small source
packages, because that requires them 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 I 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) in order to avoid
having a very large number of very small source packages.
* When an executable is installed, it must work.
- That is, its dependencies must be sufficient.
- Exception: if it's in /usr/share/doc/*/examples it doesn't have to work.
* 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.
* 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.
> The outcomes could be,
>
> a) CTTE agrees with ftp masters in rejecting ruby-task-list source package with
> node-deckar01-task-list binary added to existing ruby-task-list binary
> (currently in the master branch of [6]https://salsa.debian.org/ruby-team/
> ruby-task-list).
>
> b) CTTE disagree with the rejection of ruby-task-list source package with
> node-deckar01-task-list binary added to existing ruby-task-list binary. But
> since CTTE cannot overrule ftp masters, the decision stands unless overruled by
> a GR.
I'm confused. Why are you asking the CTTE for advice on ruby-task-list,
a package that does not appear to contain an executable, and using
this as input into #921628, a bug that is specifically about packages
that contain executables? These are not the same. If you want to ask
us about a disagreement, please don't ask us to give advice about a
different disagreement.
smcv
Reply to: