Your message dated Wed, 18 Dec 2019 22:55:16 +0000 with message-id <20191218225516.ga257...@espresso.pseudorandom.co.uk> and subject line Bug#934948: Dropping dependencies to avoid extra binary package when same source package targets more than one environment has caused the Debian Bug report #934948, regarding Dropping dependencies to avoid extra binary package when same source package targets more than one environment to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact ow...@bugs.debian.org immediately.) -- 934948: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
--- Begin Message ---Package: tech-ctte Hi members of CTTE, 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. I have been told already that CTTE cannot overrule an ftp master decision, so I'm just asking for opinion of the CTTE. If your opinion is favorable to me, it can help me if decide to start a GR eventually. I was also told to contact CTTE and DPL before going for a GR by js team members. Packages with disagreement are node-autoprefixer and ruby-task-list. Though ftp masters stated on irc, node-autoprefixer will not be accepted, it was eventually accepted and in the archive. But ruby-task-list was rejected. If I follow ftp master recommendation, node-autoprefixer binary should just provide libjs-autoprefixer . But it means anyone installing libjs-autoprefixer will have nodejs installed, even though libjs-autoprefixer can work without nodejs installed (it will be served by a web server and executed by a browser). In the same way, ruby-task-list binary should provide node-deckar01-task-list. So anyone installing node-deckar01-task-list will get ruby and other dependencies of ruby-task-list installed even though it is not necessary. Same way anyone installing ruby-task-list will get nodejs unnecessarily. Alternatively, if I drop nodejs and ruby dependencies, any package depending on ruby-task-list will have to add ruby-task-list's dependencies as its own dependencies. Summary of the situation, initially shared with Ruby and JS teams: https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2019-August/034881.html Initial discussion with ftp masters (readable via a matrix client): https://matrix.to/#/!saEdMDOolDMHFHsdhS:matrix.org/$15495421281854XktcP:poddery.com I have to copy each message from riot separately. Here it is, Me: please review node-autoprefixer, it adds libjs-autoprefixer binary required to replace embedded copy of autoprefixer.js in ruby-autoprefixer-rails waldi: Pirate Praveen: you have been asked to not do that me: waldi: this time there is a valid reason unlike the previous cases waldi: Pirate Praveen: no. nodejs as dependency is no reason me: waldi: I'd like to ask this as an official statement from ftp team and I'd like to challenge it with CTTE should I open a bug agianst ftp.debian.org? ScottK: Pirate Praveen: CTTE can't overrule FTP team. The only way to overrule a delegate is GR. Just so you know what you're in for. Gannef, and yes, open a bug. highvoltage: Pirate Praveen: fwiw, I know that that path will take you nowhere, the ftp teams's advice here is sound and upwards of 99% of DDs will agree with their judgement here, it's going to be futile to fight it, I suggest you rather find a better solution for the package, that's a better way to spend your (and everybody elses) energy me: highvoltage: fine, at least let this be on record highvoltage: policy is quite clear on it and there's even an entire wiki page on the topic (https://wiki.debian.org/EmbeddedCodeCopies), I guess if you need further records on that, then that's your business waldi: highvoltage: it's not about code copies. but about adding additional binary packages just to avoid one dependency me: Ganneff: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921628 highvoltage: ew that's even worse Clint: ... Gannef: it does sound like a plenty bad idea And some more... Bug asking ftp masters for official statement (no response till now): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921628 I think such policies should be applied consistently to all packages (it was inconsistently applied in the two packages I refer) and published (currently there is no official statement). 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 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. Thanks Praveen -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
--- End Message ---
--- Begin Message ---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 ---