[Pkg-javascript-devel] parallel installation

[Ross Gammon]

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:
>>> [meant to reply to the list, so sending again]
>>>
>>> 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 :-)

I believe upstream "intended to be used in this way".

But I don't really want to argue about it any more, and I am happy to go
with what the team agrees.

Ross