Your message dated Wed, 18 Dec 2019 22:55:16 +0000
with message-id <[email protected]>
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 [email protected]
immediately.)
--
934948: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948
Debian Bug Tracking System
Contact [email protected] 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.
--
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 ---
