Quoting Xavier (2020-12-03 18:42:17) > Le 03/12/2020 à 18:21, Jonas Smedegaard a écrit : > > 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. > > One other time I may have misunderstood; if so, I'm very confused. > > If ftpmasters ask us to minimize package number by embedding > to-little-modules and if then we decide to publish them as separated > binary packages, I don't succeed to understand the benefit. Then we > should return back to previous policy: one source = one package?
My understanding is that ftpmasters dislike small *source* packages. Small source packages is a burden in *every* package tracking in Debian. Small binary packages is also a burden in *some* package tracking. Zero-size binary packages is also a burden in *some* package tracking, but I don't hear ftpmasters complain about task packages. This bug 976331 is *not* about repackaging embedded modules as separate *source* packages, but only about exposing embedded modules as *binary* packages - either virtual or real ones. - 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