<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 08/18/2017 08:53 PM, Jonas
Smedegaard wrote:<br>
</div>
<blockquote type="cite"
cite="mid:150308243474.9314.6892351416691458501@auryn.jones.dk">
<pre wrap="">Quoting Ross Gammon (2017-08-18 19:54:50)
</pre>
<blockquote type="cite">
<pre wrap="">On 08/18/2017 06:09 PM, Jonas Smedegaard wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Quoting Ross Gammon (2017-08-18 16:47:10)
</pre>
<blockquote type="cite">
<pre wrap="">On 08/18/2017 04:50 AM, Hubert Chathi wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On Wed, 16 Aug 2017 09:27:49 +0200, Ross Gammon
<a class="moz-txt-link-rfc2396E" href="mailto:javascript@the-gammons.net"><javascript@the-gammons.net></a> said:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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]
<a class="moz-txt-link-freetext" href="https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles">https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles</a>
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">It is an _upstream_ antipattern, and is indeed a convenience for
them.
</pre>
<blockquote type="cite">
<pre wrap="">I agree that it should be discouraged though, except in rare cases.
It is just a normal transition (like in C/C++) after all.
</pre>
</blockquote>
<pre wrap="">Not sure if you agree with policy or try argue against it.
</pre>
<blockquote type="cite">
<pre wrap="">Whether it is bundled, or several versions of the same upstream are
packaged separately, you still have the issue of code duplication,
</pre>
</blockquote>
<pre wrap="">No, several versions of a library is not convenience code copies.
</pre>
<blockquote type="cite">
<pre wrap="">and the possibility that a security update might be required in
several places at the same time.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">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 :-)
</pre>
</blockquote>
<pre wrap="">
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).
</pre>
<blockquote type="cite">
<pre wrap="">I believe upstream "intended to be used in this way".
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
<blockquote type="cite">
<pre wrap="">But I don't really want to argue about it any more, and I am happy to
go with what the team agrees.
</pre>
</blockquote>
<pre wrap="">
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
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<p><br>
</p>
<p>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
(<a class="moz-txt-link-freetext" href="https://github.com/LeoIannacone/npm2deb/issues/15">https://github.com/LeoIannacone/npm2deb/issues/15</a>).</p>
<p>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?</p>
<p>Cheers,</p>
<p>Ross<br>
</p>
<p><br>
</p>
</body>
</html>