[Pkg-javascript-devel] parallel installation

[Ross Gammon]

Hi,

On 08/15/2017 09:20 PM, Paul Gevers wrote:
> Hi,
>
> On 14-08-17 20:38, Hubert Chathi wrote:
>> 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.
> 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.
>
>> 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.

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.

>> 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?
> 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
>
>
>

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.

Cheers,

Ross
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/pkg-javascript-devel/attachments/20170816/c7365d6d/attachment.html>