Hi Jonas, Jonas Smedegaard a écrit : > Quoting Georges Khaznadar (2022-11-04 19:49:04) > > *all* sources are contained in the upstream package, copyright owners > > and license details are in the file debian/copyright. > > Please don't stuff sources from multiple upstream sources together - see > Debian Policy § 4.13. May I compare the intented package furo with other packages? If we look at /usr/share/doc/abiword/copyright, there are more than one author and more than one free software license in the list. Regarding furo, the source which does not come from the main developer is gumshoe-patched.js, authored by Chris Ferdinandi three years ago, under MIT license. cfernandi's original work is at https://github.com/cferdinandi/gumshoe/blob/master/src/js/gumshoe/gumshoe.js and Pradyun Gedam (furo's author) is maintaining a modified version of the script, quoting the original autor. I have been applying Debian Policy § 4.13 quite a few times, most of them about embedded copies of Javascript libraries like jquery, jquery-ui, bootstrap, and so on, which are often embedded by developers publishing their code. In such a case, the Policy states that "the Debian packaging should ensure that binary packages reference the libraries already in Debian", which I do. As far as `apt-file` can tell me, there is currently no debian package referring to gumshoe.js; if I apply the Policy in a stric fashion, then "If the included code is not already in Debian, it should be packaged separately as a prerequisite if possible.", and as a footnote in the policy I can read "Having multiple copies of the same code in Debian is inefficient, often creates either static linking or shared library conflicts, and, most importantly, increases the difficulty of handling security vulnerabilities in the duplicated code." However, as there is no debian package currently using gumshoe.js, packaging it separately would not reduce any redundancy. On the other hand, which version of the script should be packaged? cferdinandi's version? As my goal is to package furo, which is used by the last version od sympy, which I am maintaining, sould I rather package separately gumshoe-patched.js, which was modified by Pradyun Gedam? I am feeling that this point in our discussion is much about the level of granularity of debian packaging: the smallest the grains, the more flexibility for reusing them in combination with others. However packages reused by a single other package are not beneficial. > > However this black box took human-readable source files (SASS source > > files and JS scripts) and created human-readable target files (CSS files > > and JS scripts). > > Whether generated code is human-readable or not is irrelevant for the > policy that all source must be in Debian. Instead it is a must that all > sources and also all tooling to generate is in Debian. I agree with you. This is ensured by the way Debian packages are rebuilt: they are inside a clean environment, and no access to Internet, with the exception of Debian package repositories. I did not package furo differently. So, the point is to decide whether the two files in debian/patches can be allowed: furo.dist-info.patch (19K), and furo.patch (213K), which were manually derived from the source (using pip for the first one, and webpack tainted by non-debian plugins for the second one), then thoroughly reviewed to detect irregularities. On the other hand, reading your previous e-mails in this thread, I discovered that you packaged rsass a few months ago, many thanks for that work! Maybe rsass would provide the right solution to furo's packaging difficulties, as compiling the sass source files is the trickiest point? Unfortunately, when I gave try, the result was disappointing: --------------8<----------------------- $ rsass furo.sass Error: "furo.sass" is not a css or sass file. --------------8<----------------------- $ cat furo.sass @import "~normalize.css" @import "variables" @import "base" @import "scaffold" @import "content" @import "components" @import "shame" --------------8<----------------------- As rsass' man page tells it, I had a look at https://sass-lang.com/, particularly https://sass-lang.com/documentation/at-rules/import to know whether "@import" should be supported or not. That page announces @import's usage would be discontinued, if favor of @use. However, even when every @import are replaced by @use, rsass complains that the file furo.sass is "not a css or sass file". Then I had a try with ruby's sass command. It could compile source sass files, with a small patch applied (replacing a few ":" by "\:" and erasing a few comments). The only caveat was that `@import "~normalize.css"` could not be interpreted. However this latter import can be made with a short sed script. I read also in your previous e-mails that you would like sass files to be distributed under /usr/share/sass, so other people can reuse them. Given the current instabilities of rsass ans sass commands with furo's sass files, is it worth publishing them at such a location? I shall rework furo's packaging to automate the generation of static files, with Debian-only tools, and send a new package via the NEW queue. Thank you for hints about Debian sass tools, in your previous e-mails. Best regards, Georges. > > > - Jonas > > -- > * Jonas Smedegaard - idealist & Internet-arkitekt > * Tlf.: +45 40843136 Website: http://dr.jones.dk/ > * Sponsorship: https://ko-fi.com/drjones > > [x] quote me freely [ ] ask before reusing [ ] keep private -- Georges KHAZNADAR et Jocelyne FOURNIER 22 rue des mouettes, 59240 Dunkerque France. Téléphone +33 (0)3 28 29 17 70
Attachment:
signature.asc
Description: PGP signature