[Pkg-javascript-devel] parallel installation

[Hubert Chathi]

On Sat, 19 Aug 2017 12:32:39 +0200, Mathias Behrle <mbehrle at debian.org> said:

> * Hubert Chathi: " [Pkg-javascript-devel] parallel installation" (Mon,
> 14 Aug 2017 14:38:34 -0400):

> I appreciate very much the initiative to find a common procedure for
> making different versions of JS libs available while still being
> compliant to policy.  The very special use case for me is tryton-sao
> [1], which was already in NEW but which I had to withdraw, because it
> didn't (and still does not) support the jquery version in stretch.

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

> I wonder why we should not also support MAJOR.MINOR as VER, if needed
> in special cases. I am not that familiar with the JS world, but I
> think to remember, that e.g. jquery didn't always follow properly
> semver and in such cases it could be necessary to have a special MINOR
> available in the archive.

There isn't really a problem with MAJOR.MINOR as VER.  The reason that
I say that "VER would be the major version number" for libraries that
follow semver is that it's what semver says.

What's really important is that VER indicates that the API is stable
with newer releases of that version.  That is, a package that depends on
libjs-fooVER >= x won't break due to API changes in versions after x; if
the library breaks API compatibility, then VER needs to be bumped in
some way or another.  So yes, if upstream breaks API compatibility with
some minor version numbers, then the minor version number will be part
of VER.  (In the C/C++ world, the SONAME (and hence the version embedded
in the package name) is just the major version number, but one
counterexample seems to be libssl, which includes minor and even
sub-minor version numbers in the package name).

I'll try to draft a policy with some accompanying documentation over the
next few days.

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