Re: [Pkg-javascript-devel] Javascript policy and npm2deb
On Wed, 11 Oct 2017 16:19:30 +0530, Pirate Praveen <prav...@onenetbeyond.org> said: > Hi, In a recent bug report, I came across this disparity, > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=877213#36 > npm2deb creates source packages with node- prefix. I think the policy > should be updated to reflect this. Yup. https://wiki.debian.org/Javascript/Nodejs/Manual says that the source package should be called "node-", which is clearly a conflict with what https://wiki.debian.org/Javascript/Policy says. It becomes even more silly when you have a source package that happens to build, say, a Node library, a Python module, and a C library, since you may end up with a Python package whose source package is named "node-something". (In fact, if emscripten ever becomes usable in Debian again, I have one source package that could potentially produce binary packages for JavaScript, NodeJS, Java, Python, Objective-C, and C. It would be fun if the Python and Java policies also told me how to name the source package.) IMHO, the policies should not mandate a source package name, which is partially why I omitted it from my proposed JavaScript policy (https://wiki.debian.org/HubertChathi/JavaScriptPolicy -- which I still need to update). It might be fine to *suggest* a name, but I don't think it should be a "should"/"recommend" (at least not in the sense that those words are used in the Debian Policy Manual). My preference would be to completely remove those clauses from the policies, but at the very least, the node and JavaScript policies should be made consistent. -- Hubert Chathi <uho...@debian.org> -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] parallel installation
On Tue, 19 Sep 2017 22:27:34 +0200, Paul Gevers <elb...@debian.org> said: > Hi Hubert, Thanks for writing this down. > On 19-09-17 17:58, Hubert Chathi wrote: >> https://wiki.debian.org/HubertChathi/JavaScriptPolicy >> >> Please let me know what you all think of it, and suggest >> improvements/fixes/etc. > I was wondering how you envision the following: "The source package > name may also include the APIVERSION in its name." I mean, if the > binary package should contain it, and there are multiple versions, > shouldn't the source package also contain it? Or is this related to > the last paragraph of that chapter? In general, I went for more permissive language rather than mandating what *has* do be done, partly in order to account for the status quo. So you are right that if two source packages provide different APIVERSIONs, then they need to have different names. But what I didn't want to do was to automatically make every JavaScript package that's currently in Debian non-compliant, which is what would happen if I we made it a "MUST". What I was thinking of was, to pick a random example, libjs-jquery is currently built from the jquery source package. If a new jQuery comes out which breaks the API, then the new source package would be named, say jquery4 or jquery3.3 or whatever, while the old source package would remain plain "jquery". I would be fine changing that to a "should", if other people would prefer that. > Also, I think we want some more words when the package with APIVERSION > is "updated" with a newer version. I.e. I think it shouldn't be > updated when you still want to provide the old APIVERSION, but instead > there should be a new package. Or are you envisioning to provide > multiple APIVERSIONs from the same source (I would recommend against > that, although since the latest uscan version less so). I'm not sure what kind of situation you're referring to. Maybe you can explain a bit more? If a library still provides an old APIVERSION, then it can still keep the same APIVERSION. Unless you're talking about the situation where a library provides an old APIVERSION but it's deprecated and will be removed in a future version. So, say, foo1 uses the old API, foo2 has both the old API and the new API, and foo3 has just the new API. In that case, I guess foo2 could be packaged as libjs-foo2, with a "Provides: libjs-foo1". Would this solve the situation you're thinking of? > Last time we discussed a target for how many APIVERSIONs are > allowed. I don't remember quickly what came out of that discussion, > but maybe having the discussion (or different opinions) reflected in > the policy as point to consider may be appropriate. I don't think there was a consensus on how many APIVERSIONS to allow, or whether there should be any limit at all. I could probably add in some language saying something about trying to limit the number of versions packaged to a "reasonable" number. BTW, I seem to have omitted the "Exclude auto-generated files from source" section entirely, which was not intentional. So until I add that back in, then pretend that it's at the bottom of my proposal. I did remove the bit about the "source package name should be called foo.js" on purpose, since it seems not many packages actually follow that. But I can re-add that if others think it should go back in. -- Hubert Chathi <uho...@debian.org> -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] parallel installation
On Sat, 19 Aug 2017 12:32:39 +0200, Mathias Behrle <mbeh...@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 <uho...@debian.org> -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
Re: [Pkg-javascript-devel] parallel installation
[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[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] https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles If upstream follows semver properly, then it shouldn't be that hard -- we'd just need one package for each major version that is actually being used (though as Paul suggested, it may be a good idea to limit the number of versions that we actually have). If upstream keeps breaking their API, then it may be a good idea for the package maintainers to talk to upstream about that. I know that several DDs have had to educate their upstreams about how to use SONAMEs in C/C++ libraries, resulting in more usable libraries. -- Hubert Chathi <uho...@debian.org> -- https://www.uhoreg.ca/ Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368 -- Pkg-javascript-devel mailing list Pkg-javascript-devel@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
[Pkg-javascript-devel] parallel installation
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.
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 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?
--
Hubert Chathi <uho...@debian.org> -- https://www.uhoreg.ca/
Jabber: hub...@uhoreg.ca -- Matrix: @uhoreg:matrix.org
PGP/GnuPG key: 4096R/F24C F749 6C73 DDB8 DCB8 72DE B2DE 88D3 113A 1368
--
Pkg-javascript-devel mailing list
Pkg-javascript-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-javascript-devel
