[Pkg-javascript-devel] Bug#976331: Bug#976331: Bug#976331: [JS Policy] what to set in "Provides" field ?

Thu Dec 3 18:17:50 GMT 2020

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20201203/9b7b6a31/attachment.sig>