On 2019, ഓഗസ്റ്റ് 21 7:06:34 PM IST, Simon McVittie <s...@debian.org> 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 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?
I was not using this command personally so I was OK to remove nodejs dependency
if it was rejected. But it was accepted later. Since the inconvenience was not
very big, I did not take up the issue with CTTE or others. I am referring it
here only for showing the previous discussion we had.
>* 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.
No, their objection is that (as far as I understood, they have not clarified it
till now even though I opened a bug) - there is no need to avoid dependency on
nodejs for the browser library.
>* 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.
Yes, in the ideal case. But since I was not very particularly interested in
this particular executable, I did not follow up on my general disagreement. I
was willing to remove nodejs dependency and work around the issue of having to
install nodejs for browser library. I was willing to remove ruby dependency
from ruby-task-list in the same way, but when I actually started removing the
dependency, I realized it was not just ruby, but it had other dependencies too.
They are,
ruby | ruby-interpreter, ruby-rack, ruby-activesupport, ruby-html-pipeline
So in gitlab, I will have to add these dependencies too. I have to make sure
this is up-to-date when new versions of ruby-task-list is release. The same has
to be done for any other package depending on ruby-task-list. If it was just
ruby, then you can expect the dependency will be present in any application
depending on it. But we cannot have the same assurance for other dependencies.
>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.
FTP masters consider both cases are same as quoted earlier.
"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."
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.
> smcv
