<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi,<br>
<br>
On 08/15/2017 09:20 PM, Paul Gevers wrote:<br>
</div>
<blockquote type="cite"
cite="mid:e704b16e-6393-eb69-aa80-785e4386f27c@debian.org">
<pre wrap="">Hi,
On 14-08-17 20:38, Hubert Chathi wrote:
</pre>
<blockquote type="cite">
<pre wrap="">At the BoF at DebConf, we were talking about parallel installation of
different versions of JS libraries. In order to do parallel
installation, we'd need differently named packages for different
versions, and it seems like the obvious way to do that is to have
packages called something like libjs-fooVER and node-fooVER, where VER
some sort of the API version, similar to the way that C/C++ library
packages are named after the library SONAME. If upstream follows semver
properly, then VER would be the major version number.
</pre>
</blockquote>
<pre wrap="">
This sounds like a reasonable approach, but what I am missing is a
recommendation on what to do to keep the number of packages limited. I
think it is not such a great idea to replace one problem (not the right
version) with another one (too many packages to support).
One approach could be for example the following. Try to have only two
versions per release, but really limit the number to a maximum of 3.
</pre>
<blockquote type="cite">
<pre wrap="">For libjs-fooVER, the JavaScript files would probably go in
/usr/share/javascript/fooVER/ rather than /usr/share/javascript/foo.
Obviously everything that previously pointed to the old place would have
to now point to the new place, but we could create a libjs-foo
transitional package libjs-foo that symlinks /usr/share/javascript/foo
to /usr/share/javascript/fooVER so that existing packages don't break.
</pre>
</blockquote>
</blockquote>
<br>
For libjs stuff, this is generally aligned with how things are
managed upstream. I have seen many apps looking for a particular
version of js stuff on an online CDN anyway.<br>
<br>
<blockquote type="cite"
cite="mid:e704b16e-6393-eb69-aa80-785e4386f27c@debian.org">
<blockquote type="cite">
<pre wrap="">
For node-fooVER, the logical analogue would be to put the files in
/usr/lib/nodejs/fooVER. However, anything that uses the library does
"require("foo")", and so would not be able to find it there. There are
a couple possible options for fixing that I can think of. The first is
to change all "require("foo")" to "require("fooVER")", but that sounds
painful to do. The second option is to add a symlink from
node_modules/foo to /usr/lib/nodejs/fooVER in the root directory of the
thing that requires foo. I think the second option is the best,
especially since Node upstream seems to prefer searching for things in
node_modules rather than in /usr/lib/nodejs. And again, we may want to
create a transitional package node-foo that symlinks /usr/lib/nodejs/foo
to /usr/lib/nodejs/fooVER.
What are peoples' thoughts on this?
</pre>
</blockquote>
<pre wrap="">
For packages that are somewhat forgiving and/or want to migrate when
required, it may make sense to not think about the *-foo packages as
transitional packages, but as the default, which will always point to
the latest version. Honestly, I rather depend on such a package and fix
bugs as they come than having to keep an eye out for updates and update
the dependency to the latest version.
Paul
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
</blockquote>
<br>
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.<br>
<br>
Cheers,<br>
<br>
Ross<br>
</body>
</html>