[Pkg-javascript-devel] Plan for legacy rollup plugins in bullseye (was Re: node-rollup-plugin-inject 4.0.2+~3.0.2-1 MIGRATED to testing)

[Xavier]

Le 27/10/2020 à 17:38, Jonas Smedegaard a écrit :
> Quoting Xavier (2020-10-27 14:45:40)
>> Le 25/10/2020 à 11:57, Jonas Smedegaard a écrit :
>>> Quoting Xavier (2020-10-25 11:27:55)
>>>> Le 25/10/2020 à 09:06, Pirate Praveen a écrit :
>>>>> On 2020, ഒക്‌ടോബർ 25 10:09:13 AM IST, Debian testing watch <noreply at release.debian.org> wrote:
>>>>>> FYI: The status of the node-rollup-plugin-inject source package
>>>>>> in Debian's testing distribution has changed.
>>>>>>
>>>>>>  Previous version: (not in testing)
>>>>>>  Current version:  4.0.2+~3.0.2-1
>>>>>
>>>>> Are we going to maintain legacy versions of these plugins in 
>>>>> bullseye? I agree adding them makes the transition easier, but 
>>>>> removing the legacy copies should also be part of the plan to 
>>>>> avoid maintaining multiple versions of these plugins.
>>>>
>>>> Hi,
>>>>
>>>> you're right, however there are a lot of outdated modules in JS 
>>>> Team packages, and these rollup plugins have no known 
>>>> vulnerabilities.
>>>>
>>>> We can also facilitate transition using this way (using 
>>>> experimental of course):
>>>>  * remove legacy module from any node-rollup-plugin-*
>>>>  * insert our own legacy modules in them including just:
>>>>    * /usr/share/nodejs/rollup-plugin-foo/package.json
>>>>
>>>>      { "name":"rollup-plugin-foo",
>>>>        "main":"index.js",
>>>>        "dependencies":{
>>>>          "@rollup/plugin-foo": "*"
>>>>        }
>>>>      }
>>>>
>>>>    * /usr/share/nodejs/rollup-plugin-foo/index.js
>>>>
>>>>      module.export = require("@rollup/plugin-foo");
>>>>
>>>> Note that transition of node-rollup-plugin-commonjs won't be easy 
>>>> (remember 10.0.1+really.9.2.0). Same for 
>>>> node-rollup-plugin-node-resolve
>>>
>>> Do I understand you correctly that you propose to ship legacy 
>>> library embedded with consuming packages?
>>>
>>> That seems backwards to me - what would be the benefit?
>>
>> Upstream chose to rename its rollup-plugin-foo to @rollup/plugin-foo. 
>> For now, I modified all of them: I embedded in node-rollup-plugin-foo 
>> both libraries:
>>  * main source is @rollup/plugin-foo
>>  * a component named "legacy" that embeds old node-rollup-plugin-foo
>>
>> Most of them have non breaking changes. Then instead of keeping an 
>> outdated library, I propose to install only @rollup/plugin-foo and add 
>> a very simple /usr/share/nodejs/rollup-plugin-foo that returns 
>> @rollup/plugin-foo (see above). This permits legacy removal and avoids 
>> to maintain a lot of patches in nodejs packages that uses them. No 
>> urgency for now since there are no security issues.
>>
>> Some of @rollup/plugin-foo *have* breaking changes, at least 
>> @rollup/plugin-commonjs and @rollup/plugin-node-resolve //(our legacy 
>> node-rollup-plugin-{commonjs,node-resolve} are already outdated)//. 
>> Propositions:
>>  1. keep packages with both libraries
>>  2. try to patch all packages that uses them, then remove "legacy"
>>     component (no urgency for now since there are no security issues)
>>
>>> I think it is better to ship legacy library with non-legacy library, 
>>> to ease tracking of its continued need and maintain it where there 
>>> is most knowledge about the library, but I may be missing 
>>> something...
>>
>> Sorry, I didn't understand, would you like to keep current situation 
>> (I'm OK with this) or remove legacy component (I'm OK too)?
>>
>> I'm so sorry, my poor English (neither the help of Google Translator) 
>> makes me unable to understand the meaning of "to ship" here (send in 
>> package or send outside package?).
> 
> Sorry for my sloppy language - "to ship" means "to include in our 
> shipment" a.k.a. "to distribute".
> 
> Let me try again:
> 
> In my previous email I worried that your proposal was to _only_ include 
> modern code in rollup plugin packages, and include a copy of old plugin 
> code into each package that needed old code.  I.e. this:
> 
>  * pkg:node-rollup-plugin-foo
>    + include modern @rollup/plugin-foo
> 
>  * pkg:node-bar-depending-on-old-foo
>    + include old rollup-plugin-foo
> 
>  * pkg:node-baz-depending-on-old-foo
>    + include old rollup-plugin-foo

Thanks ;-)

> I would prefer - and now think that this was your proposal (both now and 
> before - that I simply misunderstood you before) - that we instead do 
> this:
> 
>  * pkg:node-rollup-plugin-foo
>    + include modern @rollup/plugin-foo
>    + include old rollup-plugin-foo
>    + Provides: node-rollup-plugin-foo (= $OLD)
> 
>  * pkg:node-bar-depending-on-old-foo
>    + Depends: node-rollup-plugin-foo (= $OLD)
> 
>  * pkg:node-baz-depending-on-old-foo
>    + Depends: node-rollup-plugin-foo (= $OLD)

Right, that's what I did for all @rollup/plugin-*

Both @rollup/plugin-foo and rollup-plugin-foo have the same Debian name.
I tried "Provides: ${nodejs:Provides}", and Debian tools looks to accept
it (both build and local install with `dpkg -i`) :

  Package: node-rollup-plugin-alias
  Version: 3.1.1+~2.2.0-4
  Provides: node-rollup-plugin-alias (= 2.2.0)

Do you think this is an acceptable way?