Re: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On Thu, Jun 25, 2020 at 01:41, Pirate Praveen wrote: On Tue, Jun 23, 2020 at 2:40 pm, Sean Whitton wrote: Thanks. I think at this point we probably need to wait to hear from Bastian, who processed the REJECT. In the meantime, it would be good to reupload with the reason for the binary package split documented, as previously described. I have added a debian/README.Debian, mentioned this in the changelog and uploaded again. It is over two weeks since I added debian/README.Debian, some feedback on it (if it is sufficient or if you need more time to discuss it inside team) would be good. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On Tue, Jun 23, 2020 at 2:40 pm, Sean Whitton wrote: Hello, On Tue 23 Jun 2020 at 01:47AM +02, Jonas Smedegaard wrote: 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). Thanks. I think at this point we probably need to wait to hear from Bastian, who processed the REJECT. In the meantime, it would be good to reupload with the reason for the binary package split documented, as previously described. I have added a debian/README.Debian, mentioned this in the changelog and uploaded again. -- Sean Whitton -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
Hello, On Tue 23 Jun 2020 at 01:47AM +02, Jonas Smedegaard wrote: > 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). Thanks. I think at this point we probably need to wait to hear from Bastian, who processed the REJECT. In the meantime, it would be good to reupload with the reason for the binary package split documented, as previously described. -- Sean Whitton -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [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.
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [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 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [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
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On 2020, ജൂൺ 21 11:55:54 PM IST, Jonas Smedegaard wrote: >Quoting Sean Whitton (2020-06-21 18:47:57) >> [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). >> >> 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 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 for the clarification, Sean. > >I think that was quite helpful. I will let Pirate Praveen continue from >here. Thanks Jonas for asking this question. I hope my explanation was clear. >@Sean: You posted twice to the list, but I accidentally rejected one of >them - if the other mail was relevant then please send again and I will >approve. Sorry for the confusion. > > > - Jonas > -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On 2020, ജൂൺ 21 10:17:57 PM IST, Sean Whitton 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. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
Quoting Sean Whitton (2020-06-21 18:47:57) > [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). > > 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 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 for the clarification, Sean. I think that was quite helpful. I will let Pirate Praveen continue from here. @Sean: You posted twice to the list, but I accidentally rejected one of them - if the other mail was relevant then please send again and I will approve. Sorry for the confusion. - 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 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
[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). 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 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. -- Sean Whitton -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
Quoting Scott Kitterman (2020-06-18 23:44:43) > On Thursday, June 18, 2020 4:57:52 PM EDT Pirate Praveen wrote: > > On 2020, ജൂൺ 19 1:40:09 AM IST, Bastian Blank > > wrote: > > >The introduces an unnecessary split into katex and libjs-katex. > > > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#54 > > > > * 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. > > > > 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? Hi Scott and Bastian and others in the ftpmaster team, I read above quote as an attempt at saying "hmm, I don't see the split as necessary, and to me it feels like the tech-ctte team agrees that _generally_ such split is sensible. Could you please elaborate a bit on your opinion that the introduced split into katex and libjs-katex is unnecessary? Kind regards, - 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 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On Thursday, June 18, 2020 4:57:52 PM EDT Pirate Praveen wrote: > On 2020, ജൂൺ 19 1:40:09 AM IST, Bastian Blank > wrote: > >The introduces an unnecessary split into katex and libjs-katex. > > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#54 > > * 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. > > 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? Scott K signature.asc Description: This is a digitally signed message part. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] node-katex_0.10.2+dfsg-2_amd64.changes REJECTED
On 2020, ജൂൺ 19 1:40:09 AM IST, Bastian Blank wrote: > >The introduces an unnecessary split into katex and libjs-katex. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934948#54 * 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. Do you disagree with recommendation of ctte or you don't think it does not apply here? > > >=== > >Please feel free to respond to this email if you don't understand why >your files were rejected, or if you upload new files which address our >concerns. > > >-- >Pkg-javascript-devel mailing list >Pkg-javascript-devel@alioth-lists.debian.net >https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Pkg-javascript-devel mailing list Pkg-javascript-devel@alioth-lists.debian.net https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
