On Fri, Jun 19, 2020 at 12:33 pm, Gunnar Wolf <gw...@debian.org> wrote:
Pirate Praveen dijo [Fri, Jun 19, 2020 at 12:47:51PM +0530]:
The general case was discussed earlier and a recommendation was
given at
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#54
I'd like a confirmation from you if katex was following your
recommendations or not. I think katex should be a separate binary
package because it is shipping a user facing executable. But ftp
masters don't agree with my interpretation.
Their rejection mail and explanation is given below.
Hello Praveen,
You raised this same question to me via private mail; I prefer to
answer copying the rest of the Committee, and in a public way.
I completely lack context regarding KaTeX (tried downloading its
sources, but I am a complete JS newbie and didn't get a hold on it
anywhere; don't know what components of it are packaged or not, nor
how is your proposed katex package structured, etc.), hence, there is
no way for me to express an opinion here. I do feel there is too much
soreness still expressed between you and the ftp-masters.
So, refering to the same mail you quote, the guidelines Simon
carefully worked out begin with:
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.
This is, yes, hard to achieve - but we should strive to communicate
better before getting angry and calling in the cavalry.
Simon continued with some design principles, that I understand often
impact node.js work: "We should not have very large numbers of very
small binary packages" and We should not have very large numbers of
very small source packages". Is this the case you are arguing for?
I don't want to rehash the whole set of guidelines; I want to
understand the disagreement you are presenting.
I quated the relevant part of the quideline by CTTE as a reply to ftp
masters rejectection mail.
* 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.
I think katex qualifies for a user-facing executable. It can be used
for typesetting mathematical expressions and hence should not be
included as part of libjs-katex.
Though when I quated this part and asked if they disagree, they did not
clarify why they think this part does not apply.
Quoting their reply,
> Do you disagree with recommendation of ctte or you don't think it
does not
> apply here?
You did read the rest of that, right?
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-June/043543.html
Jonas also asked them to explain their rationale here
https://alioth-lists.debian.net/pipermail/pkg-javascript-devel/2020-June/043550.html
And finally, as David already argued - We cannot overrule delegates'
decisions. The final call on whether to accept a package is
ftp-masters'. Can we ask them to better state their reasons? Probably
yes, but that's -I think- about the limit of our action scope.
I understand that. I know only a GR can overrule their decision. But I
need to discuss with more people and be sure, before I can do that. If
you think this case was within the scope of your earlier
recommendation, then that can help other project members to make a
decision if I eventually call for a GR. Also if you think my
interpretation was wrong, then probably I can step back from pushing
for a GR.