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

[Xavier]

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).

> 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.

Anyway, let's decide.

I'm not in favor of your proposal: if I need a node-very-few-module
which is provided by a package with many dependencies, I'm not happy to
depend on it. To apply that, we should then choose with precaution in
which package we will embed each code. Packaging JS is already a hudge
work, I'm not sure we need more complexity.

@JS-Team, does anyone have any other opinion? Else which option do you
choose? I'll update pkg-js-tools with your choice of course.