Debian package #118
Comments
|
Okay, lets kick this off. Debian has node.js stuck in Unstable at time of writing. It hasn't shipped in anything Stable and has not made it into Testing. For a package to ship in Debian without having to include a private copy of node.js, a break-out needs to be staged where the copy in Unstable is cleaned up to where it can get copied to Testing. The biggest problem is that it is building on a fairly limited subset of architectures supported by Debian which is what prevents the break-out. The most recent version is available in Experimental but builds on even fewer architectures. To get through packaging policy, this break-out needs to first happen. Ubuntu only copies from Unstable normally except for Long-Term Support releases where it copies from Testing. Currently an override got the 0.6.12 version from Unstable into the 12.04 Long-Term Support release and the semi-annuals since have had the same 0.6.19 copied from Unstable. Notwithstanding Ubuntu supporting fewer architectures, it is still a downstream of Debian. For Debian-style packaging to move forward a break-out needs to happen first with node.js to unjam things so that it qualifies for Stable. |
|
The issues regarding the nodejs package are do not block the packaging of pump.io for Debian, just its migration to testing/stable (as it would be missing a dependancy, nodejs)? |
|
The big thing is you have to have your dependencies in place to ship a package in Testing or Stable and if the dependencies are missing a package can & likely will be held back. node.js is _the_ major dependency and in Debian it is effectively in an unshippable state as it isn't in Wheezy and not even in Jessie. Without it breaking out of Unstable, packaging pump.io would require a _private_ copy of node.js to be included. That won't play nice with packaging policy, if memory serves, and cause problems. |
|
Even if pump.io were in Debian sid, would that be worthwhile? Given that we can reasonably predict many significant improvements in the near future, would anyone want to use a package that would soon be out of date? I'd say once we see pump.io development level off a bit, then it would be good to aim for sid. Debian experimental is a reasonable step for now IMO. Updates get there quickly. |
|
Right now going for Experimental (otherwise known as rc-buggy) is a rather bad idea. None of the downstreams to Debian pull from Experimental for their repos. Ubuntu can but that requires filling out a bit of paperwork via the requestsync command from ubuntu-dev-tools and would have to happen manually for every version update. Considering that we've got pump.io deployed and in operation on actual servers, code is in operation and is shipping. Experimental is inappropriate for pump.io in this case. A package has to marinate in Unstable for ten days before it can make it to Testing so if it is updated in the intervening time the clock will be reset. The biggest hurdle is to first get into Debian's archive. Once that happens then updates can be packaged. Waiting until coding levels off is a bad thing. I don't think coding should ever level off on this project. More eyes on it will help this piece of what is effectively "social middleware" grow. If people worry about Debian Unstable becoming out of date then that is a much deeper, far more fundamental problem that is beyond the scope of pump.io. |
|
According to https://github.com/e14n/pump.io/wiki/Debian-Installation, all the dependencies are packaged in Debian testing now. |
|
News in the Debian side: http://retout.co.uk/blog/2014/08/23/packaging-pump.io-for-debian Jessie is going to freeze in November so any help is welcome. |
|
Status of the packaging task can be seen here: https://wiki.debian.org/Javascript/Nodejs/Tasks/Pump.io |
|
👍 |
No description provided.
The text was updated successfully, but these errors were encountered: