[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Node.js and it's future in debian

On Sat, May 05, 2012 at 10:50:21PM +0200, Carsten Hey wrote:
> * Steve Langasek [2012-05-04 09:49 -0700]:
> > On Fri, May 04, 2012 at 08:38:43AM -0700, Russ Allbery wrote:
> > > 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.  ...

> If nodejs is installed later because an other package depends on it or
> recommends it, this symlink would be overwritten by dpkg without any
> prior notice.

No; one package installs /usr/sbin/node, the other installs /usr/bin/node.
So the symlink would not be overwritten.

> Instead of creating a non-packaged symlink, it could be packaged.  For
> example, the binary package node could be renamed to axnode and a new
> binary package node would contain this compatibility symlink,
> README.Debian and NEWS.Debian and depend on axnode.

I think that creating the symlink at install time would also be acceptable,
but I agree that a transitional package is an even better solution.

> On upgraded node systems, possibly existing scripts that use the old
> executable name would need to be adapted before nodejs could be
> installed if both, axnode and nodejs, would be needed.  A warning from
> apt (removed package: node) would remind the admin of this.

> The policy does not mention compatibility packages intended for upgraded
> systems and during migration, so this would violate policy as the other
> conflicts would do.  The reasons why a conflict between the ham radio
> node package and nodejs is not allowed do not apply to a conflict
> against compatibility packages, though.

They certainly do still apply:

 - We don't want any command on the path to behave in a manner surprising to
   a user of Debian familiar with the command because of a namespace

 - We don't want admins to have to be forced to choose between two unrelated
   packages to have available on the system because an upstream failed to do
   due diligence when choosing a name.

This may nevertheless be the lesser evil.  At least with a transitional
package, we could deprecate the package out of Debian after a stable
release (while still leaving it installed locally on the ham systems where
it's critical, if the admin chooses to leave it in place.)

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: