Bug#934948: Unnecessary dependencies vs multiple binary packages
On Sat, 24 Aug 2019 02:40:29 -0400 Scott Kitterman wrote: > How small is too small is a judgement call may be the FTP team member > reviewing the package. Different people will not always make the same > judgement. This is a straw man argument here. Neither the comment on node-autoprefixer nor ruby-task-list rejection was because it was small. The reason given was, "... this split is only done to save one dependency (either ruby or nodejs) from being installed." > Unless someone can figure out an actual resolvable controversy, I don't seen > any point in bothering other FTP team members with this. To the extent > anything is being requested, it seems like it's infeasible (write down exact > rules for what too small to split into multiple binaries would be and then > have all FTP team members apply the standard perfectly). > See above, this not the contention here. The contention is about rejecting extra binary when more than just ruby or nodejs dependency is present. I did not challenge small packages being rejected nor the case when split is done to save only the interpreter dependency (there is contention still about executable useful outside given language tools, but I will wait for an actual reject before challenging it). -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#934948: Unnecessary dependencies vs multiple binary packages
On Sat, 24 Aug 2019 02:40:29 -0400 Scott Kitterman wrote: > Unless someone can figure out an actual resolvable controversy, I don't seen > any point in bothering other FTP team members with this. To the extent > anything is being requested, it seems like it's infeasible (write down exact > rules for what too small to split into multiple binaries would be and then > have all FTP team members apply the standard perfectly). I don't think ruby-task-list was rejected because the new binary was small. In the reject mail it was already acknowledged. "While the (compiled) javascript part is quite large (8k), this split is only done to save one dependency (either ruby or nodejs) from being installed. We've talked about this." ruby-task-list depends on not just ruby, ruby | ruby-interpreter, ruby-rack, ruby-activesupport, ruby-html-pipeline So if I remove these dependencies from ruby-task-list, then every package depending on ruby-task-list will have to add these dependencies themselves. I don't think its reasonable to expect every package depending on ruby-task-list to already depend on these packages too. My contention is that ruby-task-list case is not same as node-autoprefixer and it should be allowed to create two separate binary packages targeting ruby and nodejs environments. -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#934948: Unnecessary dependencies vs multiple binary packages
On Mon, 26 Aug 2019 13:55:11 +0100 Simon McVittie wrote: > That doesn't answer my question. > > I looked at this executable again and it seems as though its purpose is > to query metadata about the autoprefixer nodejs library, analogous to > the -config programs sometimes found in -dev packages (sdl2-config and > so on). Is that correct? > > Is it run automatically by some piece of Node infrastructure (like the > way the build systems of some SDL games automatically run sdl2-config > to learn which compiler and linker options they should use for SDL), > or is it intended to be run manually by a developer, or what? > > Is there any situation in which it would be run by a developer who does > not already know that they have nodejs installed? Since this package is already in the archive I'd like to focus on ruby-task-list only and reopen the discussion when another package fits the general question. > > So in general there is two cases I want to be able to create multiple > > binaries. > > > > 1. Cases like node-autoprefixer if the executable is useful (in specific > > case of node-autoprefixer , I can live without the executable for now). > > 2. Cases like ruby-task-list where there is more dependencies than the > > interpreter. > > I think these are different, and each should be considered on its own > merits, so this bug might make more sense if it is cloned (split) to offer > advice on the two different situations. As said above, I'd like to drop node-autoprefixer case from this discussion. It was mainly brought as a reference to ruby-task-list list rejection and from (my understanding of) ftp master position that both cases are similar. > For the node-autoprefixer case, if we decide that the executable is not > sufficiently important to the overall function of the package to merit a > dependency, it's probably useful to compare and contrast with cleancss.deb > from the node-clean-css source package (which *is* a separate binary > package, and it looks to me as though that was the correct decision). So can we focus on ruby-task-list case for this bug? > smcv > > -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#934948: Unnecessary dependencies vs multiple binary packages
On Wed, 21 Aug 2019 at 22:59:50 +0530, Pirate Praveen wrote: > On 2019, ഓഗസ്റ്റ് 21 7:06:34 PM IST, Simon McVittie wrote: > >* 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? > > I was not using this command personally so I was OK to remove nodejs > dependency if it was rejected. That doesn't answer my question. I looked at this executable again and it seems as though its purpose is to query metadata about the autoprefixer nodejs library, analogous to the -config programs sometimes found in -dev packages (sdl2-config and so on). Is that correct? Is it run automatically by some piece of Node infrastructure (like the way the build systems of some SDL games automatically run sdl2-config to learn which compiler and linker options they should use for SDL), or is it intended to be run manually by a developer, or what? Is there any situation in which it would be run by a developer who does not already know that they have nodejs installed? > So in general there is two cases I want to be able to create multiple > binaries. > > 1. Cases like node-autoprefixer if the executable is useful (in specific case > of node-autoprefixer , I can live without the executable for now). > 2. Cases like ruby-task-list where there is more dependencies than the > interpreter. I think these are different, and each should be considered on its own merits, so this bug might make more sense if it is cloned (split) to offer advice on the two different situations. For the node-autoprefixer case, if we decide that the executable is not sufficiently important to the overall function of the package to merit a dependency, it's probably useful to compare and contrast with cleancss.deb from the node-clean-css source package (which *is* a separate binary package, and it looks to me as though that was the correct decision). smcv
Bug#934948: Unnecessary dependencies vs multiple binary packages
Looking back at the original mail, it seems like the main complaint is that the two packages were treated differently. The easiest resolution to that problem is to go ahead and remove node-autoprefixer. That'll solve the inconsistency. How small is too small is a judgement call may be the FTP team member reviewing the package. Different people will not always make the same judgement. Unless someone can figure out an actual resolvable controversy, I don't seen any point in bothering other FTP team members with this. To the extent anything is being requested, it seems like it's infeasible (write down exact rules for what too small to split into multiple binaries would be and then have all FTP team members apply the standard perfectly). Scott K
Bug#934948: Unnecessary dependencies vs multiple binary packages
Hi, Simon. Thanks for the writeup which makes things much more
comprehensible.
Simon McVittie writes ("Bug#934948: Unnecessary dependencies vs multiple binary
packages"):
> * 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?
I think the reason we do this for Python might be related to Python
interpreter version compatibility. Otherwise it doesn't seem like it
serves any purpose ?
For Perl, the actual interpreter package is perl-base. There are Perl
scripts which run with perl-base and without perl-modules. "perl" is
most a metapackage - its main purpose is to pull in perl-modules. It
is true that pure-Perl modules depend on perl-base, directly or
indirectly. When the dependency is on "perl", that pulls in
perl-modules: ie, it isn't just the interpreter. I think the primary
purpose of the dependency on perl-base (where that is what is used) is
to specify the minimum perl version.
Would anything go wrong (with Perl or Python, say) if we didn't depend
on the interpreter ? (Assuming the dependency being dropped is
unversioned.)
I am the maintainer of a Tcl extension ("chiark-tcl") which does not
Depend on any Tcl interpreter, even though there obviously needs to be
one for it to be any use. A package which uses this extension (eg
"sauce") Depends on the interpreter.
> Design principles
> =
>
> (These are principles, not hard rules, so we might need to compromise on
> some of them where they conflict.)
...
> * 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.
We have compromised on these principles on many past occasions. The
archive is full of portmanteau packages, which contain a variety of
things with different practical dependencies. We often write
Recommends or Suggests for the practical dependencies of less-critical
subcomponents.
devscripts is perhaps the best example.
> * 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.
I think this design principle should generally outweigh the previous
two.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Bug#934948: Unnecessary dependencies vs multiple binary packages
On 2019, ഓഗസ്റ്റ് 21 7:06:34 PM IST, Simon McVittie wrote:
>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?
Yes.
>* 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?
No. nodejs dependency is removed only in cases of providing a single binary
package for both nodejs and browser environments. npm2deb adds dependency on
nodejs by default, some packages which did not use npm2deb for initial
packaging may not have it added.
>* 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?
Yes.
>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.
I'm quoting the reject mail here,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921628#10
"While the (compiled) javascript part is quite large (8k), this split is only
done to save one dependency (either ruby or nodejs) from being installed. We've
talked about this."
The "talk" they were referring to was about node-autoprefixer (the irc logs I
quoted in my first email).
>* 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?
In ideal case, all nodejs libraries should depend on nodejs (npm2deb does this
by default). As per the ftp master suggestions I'm OK to remove nodejs
dependency. I mentioned this for completeness of the argument. It is true only
because of the compromise from ideal case.
node-normalize.css, for example,
>doesn't seem to have Depends on node.js?
It seems to me, this package was created manually without using npm2deb.
You can verify this by comparing the control file generated by npm2deb create
normalize.css with the control file in this package.
>node-autoprefixer
>=
>
>* The
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
Bug#934948: Unnecessary dependencies vs multiple binary packages
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.
