Le 03/12/2020 à 19:17, Jonas Smedegaard a écrit : > 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.
That's part of what I misunderstood. So OK to do this here (after ftpmaster rejection since you pushed node-serialize-javascript). But: I was able to upload a lot of packages this year because I automatized many things. So splitting all mixed packages means manually regenerating debian/control, debian/rules, debian/*.install,... This means less uploads, more obsolescence and then less security (and also less interest in doing such manual stuff).