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

[Xavier]

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