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
>>>>> <nore...@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?
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@alioth-lists.debian.net
https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-javascript-devel
