On Fri, Aug 28, 2020 at 18:24, Simon McVittie <s...@debian.org> wrote:
On Sun, 12 Jul 2020 at 13:11:48 +0530, Pirate Praveen wrote:
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.
(Not an ftp team member, etc.)
Following up on this: I think part of the issue here might be the
katex
package's Description and other metadata fields. From the version
visible
in the NEW queue:
Package: katex
Provides: node-katex (= 0.10.2+dfsg-3)
Section: javascript
Description: Fast math typesetting for the web
KaTeX is a fast, easy-to-use JavaScript library for TeX math
rendering on the
web.
.
KaTeX supports all major browsers, including Chrome, Safari,
Firefox, Opera,
Edge, and IE 9 - IE 11.
.
Node.js is an event-based server-side JavaScript engine.
To me, that doesn't look like a user-facing executable; it looks like
a JavaScript library, that happens to have an executable entry point
so unimportant that the package description doesn't even mention it.
The package's contents also seem to be 90% usr/share/nodejs/katex,
which
supports that point of view.
When I talked about user-facing executable programs like tappy,
flatpak,
kmod, libglib2.0-bin in the technical committee advice, what I had in
mind
was something more like this:
Package: katex
Section: tex (or math or web or something)
Depends: nodejs (etc.)
Description: Utility to convert mathematical expressions from TeX
to HTML
KaTeX is a fast, easy-to-use JavaScript library for TeX math
rendering on the
web.
.
This package contains a command-line utility to render
mathematical
expressions written in TeX into HTML.
(Or whatever it actually does - I might have misunderstood.)
Does this change look good to you?
https://salsa.debian.org/js-team/node-katex/-/commit/9e05ec38f30f1e195001b181c97c1b1cc56c0146
Do you see the difference in emphasis between that, and what you've
done
in the version in NEW? It's a utility that does something hopefully
useful, which you can describe in functional terms that are unrelated
to its implementation language.
Relatedly, if usr/share/nodejs/katex (perhaps excluding cli.js) and
the
"Provides: node-katex" moved into libjs-katex, would that give
libjs-katex
any undesirable dependencies? That would leave the katex.deb package
containing only /usr/bin/katex, which would make its purpose extremely
clear. It would still be tiny, and the Packages file wouldn't get any
smaller, but the dividing line between binary packages would be in a
place
that's easier to justify.
I think that is splitting the hairs, but if that is the only way to
move forward I can do that as well.
The remaining question for the maintainer and the ftp team would be:
is the /usr/bin/katex utility sufficiently general-purpose and useful
that people would genuinely want to install a package that contains
only
that utility? If they would, then I think a package as described above
makes sense. However, if it's more like an example, demo, manual test
or toy than something people would genuinely use, an alternative would
be to install it in /usr/share/doc/libjs-katex/examples, which doesn't
require a Depends on its interpreter.
If /usr/bin/katex is a useful tool in its own right and not just an
example, one thing that would provide good supporting evidence would
be
to write a man page for it, describing how to use it in terms that
make
sense for someone who wants to batch-convert TeX into HTML using a
CLI,
and does not want to have to be aware of anything specific to node.js.
It can convert TeX to html from command line, so it is not just an
example.
This is upstream documentation of using the cli,
https://katex.org/docs/cli.html
In our case, instead of npx katex, just running katex will be enough.
But I need to figure out how to convert docs/cli.md.template to a
manpage. If it was just a regular .md file I can just patch it (to
remove reference to Node.js package managers and change npx katex to
katex) and call marked-man I can't find it from package.json scripts
how the template is converted to a regular .md file. Anyone has ideas
here? Or I will have to ask upstream.
I hope that makes sense?
yes, but ftp team has just remained silent after I responded to all the
suggestions from Sean.
smcv
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
