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 collision. - 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