Quoting Xavier (2020-12-03 17:33:18) > Le 03/12/2020 à 16:36, Jonas Smedegaard a écrit : > > Quoting Xavier (2020-12-03 15:44:48) > >> Le 03/12/2020 à 15:12, Jonas Smedegaard a écrit : > >>> Quoting Xavier (2020-12-03 14:35:25) > >>>> Le 03/12/2020 à 14:24, Xavier a écrit : > >>>>> Le 03/12/2020 à 12:44, Jonas Smedegaard a écrit : > >>>>>> These source packages embed nodejs module serialize-javascript > >>>>>> without offering it as virtual binary package: > >>>>>> > >>>>>> node-compression-webpack-plugin > >>>>>> node-copy-webpack-plugin > >>>>>> node-uglifyjs-webpack-plugin > >>>>>> > >>>>>> Please embed in only one source package provided as versioned > >>>>>> virtual package, and drop in other source packages instead > >>>>>> depending on the virtual package. > >>>>>> > >>>>>> Severity raised since the lack of virtual package blocks upgrading > >>>>>> node-terser. > >>> > >>> [...] > >>> > >>>>> for now, dh-sequence-nodejs adds a "Provides" item for modules > >>>>> installed in root nodejs directories. Do we want to declare a > >>>>> "node-foo" for submodules (installed in a <package>/node_modules > >>>>> directory) ? > >>> > >>> Whatever that tool does, the resulting package should declare > >>> Provides: for each embedded Nodejs module, properly versioned with > >>> the module's own version as first segment then "~" then source > >>> package version. > >>> > >>> I cannot see a reason for *any* embedded Nodejs module to stay > >>> hidden, but if someone comes up with some exceptional cases for > >>> that, then the reasoning should be explicitly documented in either > >>> README.source or README.Debian (and possibly in long description > >>> too). > >> > >> I chose that because such modules are not directly usable using a > >> `require("foo")`, but I can change > > > > I am less interested in why historically some pattern was chosen. > > > > My interest is in what pattern to use going forward. > > > > Code in package have dependencies on code in other packages. > > > > We need to be able to declare dependencies between pieces of code. > > > > For JavaScript, code is grouped as "Nodejs modules". > > > > A a concrete example, Nodejs module rollup-plugin-terser depends on > > Nodejs module serialize-javascript. > > > > Going forward (regardless of why historically some other pattern was > > chosen), Debian package node-rollup-plugin-terser needs to be able to > > express a build-dependency on Debian package providing the Nodejs module > > serialize-javascript. > > > > > >>>> Note that the future lintian database (classification tags) will > >>>> permit to see node modules everywhere. > >>> > >>> Everywhere? > >> > >> Sorry, I miss some explanations: lintian parses all files and emit a tag > >> each time it finds a node_module/foo/package.json or > >> <main nodejs>/foo/package.json or <main nodejs/foo.js. Then we will be > >> able to see nodejs embedded module in all Debian packages. > > > > Lintian can help check if a package is valid. > > > > Lintian cannot make a package declare as virtual Debian packages the > > Nodejs modules it has embedded. > > > > > >> NB2, you can also take a look at > >> https://lintian.debian.org/tags/nodejs-module-not-declared.html : it > >> shows node module installed in nodejs main dirs (not in node_modules/ > >> for now). > > > > A web page (generated by lintian or written any other way) cannot make a > > package declare as virtual Debian packages the Nodejs modules it has > > embedded. > > > > > >> If we decide to change this ~policy, nodejs-module-not-declared should > >> also be updated. > > > > I am pretty sure that hiding generally usable embedded code violates a > > "should" somewhere in Debian Policy. > > If so, lintian should reports "error", not info/warning when a JS lib is > embedded. Ftpmasters didn't reject such packages (see jquery copies for > example).
Ideally lintian should identify and report all errors. Ideally all packaging work could be automated. Reality is slightly different. though. > > Therefore, if Debian JavaScript Policy says that generally useful > > modules should be *hidden* instead of provided as virtual packages, then > > I consider Debian JavaScript Policy broken. > > > >> But in this case, we will have some not-directly-usable node-* virtual > >> packages. > > > > Why not-directly-usable? > > > > Obviously we should not _only_ declare "Provides:" but also make sure > > that the code is actually placed in the correct location below > > /usr/share/nodejs and check testsuite and establish autopkgtest and all > > the other things that is required for packaging code. > > > > Embedded code is not magically excluded from getting properly packaged. > > You're free to think that my packages are not properly packaged. I am not targeting you, nor am I targeting dh-sequence-nodejs, nor am I targeting lintian, nor am I targeting JavaScript Team Policy. You brought those up in this _discussion_ about a package that I filed a bugreport against. > Anyway, let's decide. Decide on what exactly? My way or the highway? Your way or the highway? I notice you added [JS Policy] to the subject, but this is bug#976331 which is specifically about three Debian packages all embedding Nodejs module serialize-javascript without any of them providing serialize-javascript as a binary package. - 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