[Pkg-javascript-devel] parallel installation

[Jonas Smedegaard]

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

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20170818/d8768442/attachment.sig>