Dear Jonas, thank you, as you took the time to reply very precisely to my interrogations.
I shall add some comments, citing only some parts of the previous e-mail. Jonas Smedegaard a écrit : [ ... some parts are not cited ... ] > Fine that a source package contains sources for a fork of another > project, when the fork is intended for use uniquely as part of this > project. I compared the fork to its upstream: most of changes are beautification (better usage of indentation, and so on). The only significant change is the use of Math.ceil() to ensure that a value will be an integer, where upstream code does not take that precaution. > Also, to answer your (inmplied) question: Yes, I do find it beneficial > that our users could do "apt install libjs-gumshoe". Gumshoe.js is a rather short script, less than 500 lines. However, its author has taken the time to distribute it through https://www.npmjs.com, and the downloads are significant. So, I agree, it is worth packaging it in Debian. > Your composing a patch which involves tools like pip and webpack (with > code-pulling plugins) is the reason for my raising concerns here: > Essentially that means you get from source to generated code via helper > code not in Debian. I managed to build the CSS files with ruby's sass. I compared the result with the previous non-debianish method, here is a summary of the difference, after running css-beautify on both CSS outputs: +-----------------------------------+----------------------------------+ | debian way | non-debian way | +-----------------------------------+----------------------------------+ | normalize.css is included | normalize.css is embedded | +-----------------------------------+----------------------------------+ | nested quotes are nicely rendered | barbarian quotes rendering | | example: | example: | | url('data:image/svg+xml; | url("data:image/svg+xml; | | charset=utf-8,<svg xmlns="http:..| charset=utf-8,<svg xmlns=\"http:| | ..." ...') | ...\" ...") | +-----------------------------------+----------------------------------+ | better standards support | fuzzy syntax? | | example of a selector: | example of a selector: | | body[data-theme="dark"] | body[data-theme=dark] | +-----------------------------------+----------------------------------+ | one syntax was not rendered: | that source is rendered | | nothing is rendered from the | and yields about 80 lines of | | source: | CSS code | | @media(prefers-color-scheme: dark)| | +-----------------------------------+----------------------------------+ | no "-webkit-foo" stuff is | some "foo" statements are | | used | duplicated as "-webkit-foo" | | (neither "-moz-foo") | and sometimes as "-moz-foo" | +-----------------------------------+----------------------------------+ | in one place, #6b728080 is used | the same color is specified as | | to specify a transparent color | rgba(107, 114, 128, 0.5019607843)| +-----------------------------------+----------------------------------+ | a property named | no weird property is used. | | last-child-margin-bottom is used | | | once. | | +-----------------------------------+----------------------------------+ > Nice that you review what the non-Debian helper code did, but still > unacceptable: The process to get from source to generated form must > happen purely with Debian tools (or by changes that you can reasonably > claim to have done by hand, which 213k of auto-generated diff probably > isn't). The table above summarizes a manual review for files weighing approx. 60k; "manual" does not imply ineffective, when one uses beautifying filters and emacs' ediff-buffer tool. I compared CSS files issued by Ruby's sass and by sassc: they are quite the same when filtered by the same beautifier; among the few differences, the most notable is: decimal numbers writtent like .5 instead of 0.5. The conclusion is that Sass compilers available in Debian miss one single part of the source SASS code, the part which is about a "preferred" black theme. I could use furo as a style for sphinx, to build the latest version of package Sympy, which depends on it. The result is correct after pure-debian packaging, and I found no difference between the locally built HTML documentation and the official one, available from https://docs.sympy.org/latest/index.html :) So, building furo with pure debian tools is possible, and the result is efficient. I uploaded a new release of package furo to the NEW queue. ---oOo--- Regarding the other suggestions you made, Jonas, I would like a few more precisions: - you would like to see SASS files distributed under /usr/share/sass; is it sufficient to shape the packaging so it produces two binary packages, "furo" for the sphinx style, and "sass-stylesheets-furo" for SASS stuff? Or would it be sufficient to make a single "furo" binary, which stores SASS files under /usr/share/sass, and provides a virtual package name sass-stylesheets-furo? - you would like to see gumshoe.js packaged separately in Debian. I can issue an ITP for it. Do you estimate that making a package node-gumshoe is worth the effort, and the storage cost, for debian servers? Remember that the flesh in this package is a 500-liner script. Best regards, Georges.
signature.asc
Description: PGP signature
