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 >>> <javascr...@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, 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. >>> >>>  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.".