Re: Node.js and it's future in debian
FWIW, the ham radio node package has been in Debian since 1999
according to packages.debian.org.
On Wed, May 02, 2012 at 01:50:03AM -0500, Jonathan Nieder wrote:
>
> [...]
> > It is perfectly reasonable to have a transition plan to a new name. Given the
> > age of the two packages, I'm not inclined to give up without a good reason.
>
> I believe the huge number of scripts out there that use the "node"
> command meaning to refer to Node.js are a good reason. I don't think
> this is about giving up --- it is about making Debian work well even
> in unusual setups.
Likewise I can argue the number of people with installed ham radio systems
is a good reason NOT to change the current situation.
>
> > I know many ham radio operators who have equipment in difficult to reach
> > areas (mountain tops for instance) who would have systems break on upgrade
> > if /usr/sbin/node goes away abruptly.
>
> Is it common to upgrade without ssh or physical access to the machine
> being upgraded? If so, I imagine many other potential upgrade
> problems could pose trouble, too.
It is no uncommon to install the equipment where the only interaction with
the computer is via the radio link. Yes this creates problems when upgrading
or replacing components.
Ham radio is the "open source" (predates open source software) version of
emergency communications and during normal times communications. To ensure
coverage by radio, you need your antenna up high. You can build a tower,
use a tall building, or use a hill/mountain. Each has it's own set of access
challenges for maintaining the equipment. That is why ham radio equipment is
durable, and often designed to run without constant maintenance.
In our modern world, one of the utilities to fail in an emergency are
often the telephone and cell phone systems. If they have not suffered
physical damage, they quickly become overloaded to the point of uselessness.
Recovery from physical damage can take from hours to weeks to months to years
depending on the location.
A ham radio operator can show up with a portable antenna structure, antenna,
radio, and computer and get essential communications back in an area faster
than the utility companies in many instances.
If the high antenna / system is damaged, several hams can set up radio nodes
at lower elevations to cover the affected area. This equipment may be (and
often is) set up in advance, and not continuously running. (Yes this creates
other issues with maintaining the equipment in a state of readiness.)
Here is one potential scenario:
If someone is not paying attention, they will "upgrade" node to axnode (or
whatever) which breaks their system (unknown to them because they were
distracted during the upgrade). They respond to an emergency, only to
find their kit is broken and they have no way to fix it because there is
no internet connectivity.
The emergency communications plan has to allow for malfunctions, but now
they are operating in scramble mode instead of the "comfortable" drilled
and tested mode.
Ham radio operators do this FOR FREE, just like open source software
developers.
Changing the ham radio node without a transition plan (most likely a
multi-release plan) is throwing the ham radio people under the bus
in deference to the "current hot thing."
>
> The natural conclusion I'd take away is that the maintainer scripts
> must be robust in changing references to /usr/sbin/node in the inetd
> and ax25d configuration to point to /usr/sbin/axnode instead.
>
You will never get a script that is robust enough to do this. There
is a reason maintainer scripts don't change config files that have
been customized by the user.
I also seem to recall a Debian policy issue about not messing with
another package's files.
> I would not take away the conclusion that we should block Node.js from
> entering the archive for this.
>
I would take away that node.js is free to enter the archive immediately
if they change their binary name from /usr/bin/node to some other name not
already in Debian. The insistence on a new package using an already
established package's binary name is the problem. I believe the burden
of creating the transition should be on the node.js packager since they
are the cause of the conflict. Not that what I believe matters here.
> >> Maybe wheezy could be released with both /usr/bin/node and
> >> /usr/sbin/node present, and with configuration migrated to point to
> >> /usr/sbin/ax25-node. That configuration migrated part is way more
> >> important than the disposition of the "node" command, in my humble
> >> opinion.
> >
> > Policy does not allow this. If it did, we wouldn't be having this discussion.
>
> Where policy does not lead to Debian being better, it is irrelevant
> because it is easy to change or get an exception from the release
> team or technical committee. I hope the fix is that simple. :)
If it were "easy" to get an exception, why has this not already happened?
Policy is not irrelevant. It is one of the foundations of the Debian
project. It keeps this project's packages from being total chaos.
Changes to policy should be thoroughly discussed before implementation,
and that takes time. Exceptions to policy should be even more thoroughly
scrutinized.
Pat
Reply to: