[meant to reply to the list, so sending again]

On Wed, 16 Aug 2017 09:27:49 +0200, Ross Gammon <javascr...@the-gammons.net> 

> 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

If upstream follows semver properly, then it shouldn't be that hard --
we'd just need one package for each major version that is actually being
used (though as Paul suggested, it may be a good idea to limit the
number of versions that we actually have).  If upstream keeps breaking
their API, then it may be a good idea for the package maintainers to
talk to upstream about that.  I know that several DDs have had to
educate their upstreams about how to use SONAMEs in C/C++ libraries,
resulting in more usable libraries.

Hubert Chathi <uho...@debian.org> -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8  72DE B2DE 88D3 113A 1368

Pkg-javascript-devel mailing list

Reply via email to