Bug#963112: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On 2020, ജൂൺ 23 2:56:37 AM IST, Sean Whitton wrote:
>Hello Pirate,
>
>On Mon 22 Jun 2020 at 12:58AM +0530, Pirate Praveen wrote:
>
>> 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.
>
>Would someone want to use libjs-katex without nodejs installed?
Jonas answered it already.
>> 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.
>
>You should ensure it's visible in the source package, in
>README.{source,Debian} and/or d/changelog.
>
Okay. I will do it from next time.
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Bug#963112: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
Quoting Sean Whitton (2020-06-22 23:26:37) > Would someone want to use libjs-katex without nodejs installed? Yes: Pandoc can produce output which uses katex rendered with the Javascript interpreter of web browsers, not on OS-bound Javascript rendering like Node.js. Currently Pandoc suggests node-katex, but pulling in Node.js is unneeded baggage. For some users it may even be bad: Node.js may not be covered by security support for as long as Firefox (due to the extraordinary treatment of Firefox in stable Debian). - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#963112: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
Hello Pirate,
On Mon 22 Jun 2020 at 12:58AM +0530, Pirate Praveen wrote:
> 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.
Would someone want to use libjs-katex without nodejs installed?
> 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.
You should ensure it's visible in the source package, in
README.{source,Debian} and/or d/changelog.
--
Sean Whitton
