Quoting Georges Khaznadar (2022-11-05 11:15:53) > 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?
Sure. Just please keep in mind that two wrongs don't make a right: Similar issues in other packages might be similar bugs on those packages (rather than proof that your package is not buggy). That said, it makes great sense to compare against other packages for inspiration and for getting a better understanding of how to possibly approach some issues (and certainly helps to compare against packages maintained by those you discuss issues with ;-) ). Concretely, however, I fail to recognize your point in comparing against abiword: True, there are multiple copyright holders and multiple licenses involved, but what I pointed out being an issue was (not that, but instead) you as package maintainer stuffing together multiple upstream sources in one source package. > 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. What I reacted on was your mentioning use of npm and pip. 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. If the fork is not maintained by upstream, then better to try avoid that fork. Often best approach is to identify need for forking and propose the original-of-the-fork proj́ect to adopt needed changes. Another more tricky approach is to "fork during build" by coordinating with the Debian maintainer of original-of-the-fork project to provide source, and use that to apply a locally-by-you maintained patch during your build. If the fork is intended for reuse across multiple projects, then better to maintain packaging of that fork as a separate source package. If the fork contains (not only source but also) generated files, then best to regenerate those files during build. Yes, it is also an option to ensure in other ways that the source *can* produce the exact included generated code using only locally Debian-packaged tools, but that is often more tricky than simply regenerating the code. > 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. Your approach "increases the difficulty of handling security vulnerabilities in the duplicated code", as you quote yourself. That's the issue that concerns me here (not, as you seem to try frame it, mere nitpicking over busywork). Also, to answer your (inmplied) question: Yes, I do find it beneficial that our users could do "apt install libjs-gumshoe". Or, if the fork is truly needed, our users might quite possibly instead find beneficial to be able to do "apt install libjs-gumshoe-gedam". > > > 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. 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. 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). > 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. For older Sass/SCSS code please use sassc (as I also wrote earlier): Ruby-sass predates sassc and is nowadays discouraged! > 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. For normalize, specifically, I can recommend to replace with the maintained Sass-based normalize project available as Debian package sass-stylesheets-normalize (currently a virtual package: the feature of shared stylesheets was historically implemented in the "compass" extension to sass, but nowadays Compass is dead, the feature is implemented in sass itself, and I am slowly renaming packages from compass-*-plugin to sass-stylesheets-* to reflect that). I often use a rule like this in a Makefile: %.css: %.scss sassc --load-path /usr/share/sass --style compressed $< $@ > 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? Sass code that is written only to work for a single unique situation is obviously less interesting to offer for broader user. So if you solve issues e.g. using sed then please don't bother. But what is powerful about sass is that it is relatively easy to reuse stylesheets so that a local web designer can reuse some patterns without needing to embrace all patterns - e.g. some already apply an alternative to normalize and it is wasteful or maybe even cumbersome to include yet another. So what I encourage is to polish upstream Sass code to be reusable, and then publish it below /usr/share/sass - and then have the binary package provide matching virtual package sass-stylesheets-* to promote it. Kind regards, - 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
signature.asc
Description: signature
