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

[Xavier]

Le 06/12/2020 à 02:14, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-12-03 21:19:48)
>> 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.
> 
> [,,,]
> 
>>>>>>> I am pretty sure that hiding generally usable embedded code 
>>>>>>> violates a "should" somewhere in Debian Policy.
> 
> Here (as also mentioned elsewhere in the email thread): 
> https://www.debian.org/doc/debian-policy/ch-source.html#embedded-code-copies
> 
> 
>>>> 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).
> 
> Great that you develop tools to maintain packages more efficiently and 
> more automated.  If done in compliance with Debian Policy, that is.
> 
> Do you say that it is not possible to automate packaging with embedded 
> modules provided as virtual or real packages?  Why do you think you can 
> only develop efficient automating routines with hidden modules?

Pkg-js-tools already automates virtual package. There are 2 configuration:
 * components not declared in debian/nodejs/root_modules: installed in a
   subdirectory and not "provides"
 * components listed in debian/nodejs/root_modules: installed in main
   nodejs directory and added in ${nodejs:Provides}

So when a pkg-js-tools package does not export components, just to
insert '*' in debian/nodejs/root_modules and add a "Provides:
${nodejs:Provides}"

> Here is a concrete example of a minimal (manual) that I propose to do 
> for one of the three packages involved in this bugreport (and then have 
> the other 2 packages drop the embedded module ans instead depend on the 
> now accessible-as-package-name module): 
> https://salsa.debian.org/js-team/node-cosmiconfig/-/commit/125869f9
> 
> I don't understand how that cannot be automated.

My way is more simple and is already automatized. The problem was not
here but in separated binary packages. This is partially automatized,
see jest.

> I do see how it requires coordination across packages, to decide which 
> one source package should contain the embedded module, instead of *all* 
> source packages containing *duplicate* modules - but that coordination 
> work is *necessary work, not optional.  It is not ok to package the 
> Apache2 server with embedded zlib library, regardless if it is easier to 
> automate without unentangling things done too tight upstream. Nodejs is 
> no different from that!
> 
> ftpmaster wants to avoid too tiny source packages, but ftpmaster does 
> not want duplicate code.

No you're wrong here, they accepted a lot of embedded copies for JS (see
Jquery for example), not for C.

Also they don't want too many little binary packages (not only source).