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?
