[Pkg-javascript-devel] parallel installation

[Ross Gammon]

On 08/18/2017 08:53 PM, Jonas Smedegaard wrote:
> Quoting Ross Gammon (2017-08-18 19:54:50)
>> On 08/18/2017 06:09 PM, Jonas Smedegaard wrote:
>>> Quoting Ross Gammon (2017-08-18 16:47:10)
>>>> On 08/18/2017 04:50 AM, Hubert Chathi wrote:
>>>>> On Wed, 16 Aug 2017 09:27:49 +0200, Ross Gammon 
>>>>> <javascript at the-gammons.net> said:
>>>>>
>>>>>> For node-* stuff however, upstream handle this by bundling a 
>>>>>> particular version of a module in node_modules. If it is "really 
>>>>>> difficult" to patch a node module/app to use the Debian version 
>>>>>> of a library (because the versions have changed too much), then 
>>>>>> shouldn't we bundle the node_module and install it as upstream do 
>>>>>> it (avoiding all the relative path issues)? It could be followed 
>>>>>> up with a bug (severity wishlist/normal?) to remove the bundled 
>>>>>> module once Debian and upstream are more aligned.
>>>>> Embedding copies of libraries should be highly discouraged.  For 
>>>>> one thing, it is agaist policy[1], but it also it makes security 
>>>>> support much harder, you may end up with multiple buggy versions 
>>>>> of a library on your system, and have a bunch of duplication.  It 
>>>>> may make initial packaging easier, but it usually makes 
>>>>> maintenance harder.
>>>>>
>>>>> [1] 
>>>>> https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles
>>>> The title of this section of policy is actually "Convenience copies 
>>>> of code". It is definitely not a convenience to heavily patch a 
>>>> package just to use a "way out of date" dependency, when it is out 
>>>> of date because many other packages still require that old 
>>>> dependency.
>>> It is an _upstream_ antipattern, and is indeed a convenience for 
>>> them.
>>>
>>>
>>>> I agree that it should be discouraged though, except in rare cases. 
>>>> It is just a normal transition (like in C/C++) after all.
>>> Not sure if you agree with policy or try argue against it.
>>>
>>>
>>>> Whether it is bundled, or several versions of the same upstream are 
>>>> packaged separately, you still have the issue of code duplication,
>>> No, several versions of a library is not convenience code copies.
>>>
>>>
>>>> and the possibility that a security update might be required in 
>>>> several places at the same time.
>>> It is certainly _possible_ for a security bug to exist in multiple 
>>> upstream releases of a code project, but when tracked on its own it 
>>> is easier to hunt down such bugs, and when each version exist only 
>>> at one place in Debian then each version needs only be fixed once 
>>> for a security bug to get squashed.
>>>
>>>
>>>> Of course, bundled copies are harder to find. But we can manage 
>>>> that in the team (via a transition bug, and/or a list on the wiki?) 
>>>> while we push all the unwilling upstreams to align on the same 
>>>> version (and nodejs upstreams are REALLY unwilling on this - 
>>>> believe me). I still think it is better to manage multiple copies 
>>>> in the same way that upstream do. It will give a lot less friction 
>>>> upstream.
>>> It is not adequate to agree in this team about bundling code: As an 
>>> example, the security team tracks security bugs and will also need 
>>> to agree on such deviation from Debian Policy.
>>>
>>> Personally I do *not* find bundling easier manageable than 
>>> separately tracking each true upstream project.  You are welcome to 
>>> explore argue for that, but you will need to convince not only this 
>>> team but Debian in general.
>>>
>>>
>>>  - Jonas
>>>
>> From the policy: "Debian packages should not make use of these 
>> convenience copies unless the included package is explicitly intended 
>> to be used in this way.".
>>
>> "Should" does not equal "must", it means something closer to "maybe". 
>> This gave me some trouble in my Danish language classes :-)
> And also from policy: "Non-conformance with guidelines denoted by should 
> (or recommended) will generally be considered a bug, but will not 
> necessarily render a package unsuitable for distribution.".
>
> So yes, it does not equal "must" (and I believe I didn't claim it did), 
> but it does not equal "maybe" either (arguably you didn't claim it did - 
> but your choice of words had a real risk of being perceived that way).
>
>
>> I believe upstream "intended to be used in this way".
> I also believe that upstream intended the code they released to be used 
> the way they prepared it.
>
> But also I believe that the Debian project considers it an antipattern 
> a.k.a. a bug.
>
>
>> But I don't really want to argue about it any more, and I am happy to 
>> go with what the team agrees.
> We do not have any agreement yet, but thanks also to your input we may 
> find one.  I really appreciated your input (even if I disagree with it) 
> and hope you will continue to provide input to this discussion if you 
> have additional points or perhaps feel that some of the points you've 
> made already is being misunderstood or misrepresented. :-)
>
>
>  - Jonas
>
>
>

I agree managing the bundles for node packages would be a pain. Just
thinking about checking all the copyrights is scary enough. But a large
amount of legwork could be automated by npm3deb
(https://github.com/LeoIannacone/npm2deb/issues/15).

Anyway - if we instead separately packaged a different version of a node
module, where would it be installed? Do we have to patch all reverse
dependencies of the module so it uses the right version at runtime (when
both versions might be installed), or can we rely on some PATH trickery?

Cheers,

Ross


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20170821/e12eb51e/attachment.html>