[Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED

[Pirate Praveen]

On 2020, ജൂൺ 21 10:17:57 PM IST, Sean Whitton <spwhitton at spwhitton.name> wrote:
>[speaking as an FTP team member, not ctte member, though this is *not*
>an official statement made on behalf of the whole FTP team]
>
>Hello Jonas,
>
>On Sun 21 Jun 2020 at 10:48AM +02, Jonas Smedegaard wrote:
>
>> Could you please elaborate a bit on your opinion that the introduced
>> split into katex and libjs-katex is unnecessary?
>
>I have not looked at this particular package, but here is what I
>understand to be the team's consensus: the FTP team wants to see some
>technical purpose which is served by the binary package split, to
>justify taking up more space in the Packages file.  We will also object
>if this technical purpose could be easily served by something other than
>a binary package split (e.g. by adding Provides: entries).

We usually use Provides instead of splitting when we can remove the Depends on the interpreter. For example node-clipboard provides libjs-clipboard.js. This works when the node package does not ship a user facing significant executable. User facing executable as separate binary was recognized as a valid reason by CTTE in the ruling I quoted in my first reply.

In case of this particular package, katex binary also provide a command line interface via katex command. So we cannot drop the depends on nodejs (rc bug, nodejs is not an optional component but the interpreter needed to run the katex program). Avoiding unnecessary dependency on interpreters was achieved in all previous instances by removing the dependency on pure libraries. We expect whichever user facing program depending on the library to set Depends on the interpreter. For example gitlab depending on nodejs is enough for node-clipboard to satisfy dependency on nodejs. In this case katex itself is a user facing program not tied to nodejs development (it is used for maths typesetting). So we cannot reasonably expect a user wanting to use katex will have nodejs installed already.

>So I would assume that the FTP team member who processed this upload
>couldn't see how a technical purpose was being served by the split.  If
>Pirate could explain some technical purpose that was missed that would
>be helpful.

I thought the CTTE guideline on this specific case of user facing executable was enough. They could have just asked for an explanation before rejecting.

>I don't think that the bar is particularly high here.  Even if an FTP
>team member wouldn't themselves solve the problem by introducing a
>binary package split, if it's clear that the maintainer has consciously
>chosen to use a binary package split to solve a problem and that's a
>reasonable way to go about solving the problem, we'll sign off on it.
>

Thanks. I hope that explanation was enough. Let me know if that is not sufficient.
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.