Re: Node.js and it's future in debian
- To: email@example.com, firstname.lastname@example.org
- Subject: Re: Node.js and it's future in debian
- From: Russ Allbery <email@example.com>
- Date: Fri, 04 May 2012 08:38:43 -0700
- Message-id: <firstname.lastname@example.org>
- Mail-followup-to: email@example.com
- In-reply-to: <20120504114234.GB723@yuggoth.org> (The Fungi's message of "Fri, 4 May 2012 11:42:35 +0000")
- References: <CACxjfDH5zYth6Q-ZDLDafqNEczbF3BqaGRcAhsaiPEnApbiUuA@mail.gmail.com> <firstname.lastname@example.org> <20120428025806.GA7922@master.debian.org> <email@example.com> <20120501211011.GJ30521@flying-gecko.net> <firstname.lastname@example.org> <20120503172254.GG19468@flying-gecko.net> <CANVYNa_q009fcs_DSphG9K=D0RE21NAsQvAuKOAHug9NEHu0Pg@mail.gmail.com> <20120503182633.GI19468@flying-gecko.net> <20120504080319.GB5371@debian> <20120504114234.GB723@yuggoth.org>
The Fungi <email@example.com> writes:
> I think this is part of the misunderstanding. If these systems are nodes
> on an AX.25 network, what's being renamed (and potentially broken) is
> the userspace binary which connects the machine to the network. Think of
> it as if you're suggesting a rename of /usr/sbin/sshd to
> /usr/sbin/secureshelld. Sure it's usually only started from packaged
> scripts and managed configuration files, but when it's also your only
> way into some remote systems that has a much greater potential to render
> them indefinitely inaccessible.
Yes, this is something I'd not realized before and am now realizing.
Also, the point that starting the service from inetd isn't the only way
that it's started, and it may be embedded in custom scripts and the like,
was new information for me.
Contrary to how it may have sounded from my previous messages, it really
isn't that I want to discount the effect on the ham radio community, and I
completely agree with other posters that having Debian serve the needs of
the ham radio community is important for a wide variety of reasons.
Raphael's approach of creating a compatibility symlink in postinst during
upgrades but not for new installs sounds better to me the more I think
about it, since that addresses the major concern of breaking someone's
system during an upgrade. It's not ideal in terms of making the conflict
go away, but it does address the problem going forward, if not on
Russ Allbery (firstname.lastname@example.org) <http://www.eyrie.org/~eagle/>