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