On Sun, 6 May 2012 10:29:18 -0700, Steve Langasek <vor...@debian.org> wrote:
> On Sat, May 05, 2012 at 08:29:40AM +0100, Philip Hands wrote:
> > How about doing the following:
>
> > node package replaced by a node-legacy package that contains no more
> > than a README and a symlink node --> ax25-node, and depends on
> > ax25-node
>
> As mentioned by Carsten Hey on debian-ctte, we should certainly keep the
> same binary package name ('node') to ensure smooth upgrades for users that
> already have it installed.
>
> > ax25-node package, which contains what node does now, with the binary
> > renamed
>
> > nodejs package replaced by a node.js-legacy (or a better name if there
> > is one) package that contains no more than a README and a symlink node
> > --> node.js (or whatever), and depends on node.js
>
> > node.js package that is the nodejs package with a renamed binary.
>
> > and make node-legacy and node.js-legacy conflict.
>
> Because Node.js is a scripting interpreter, I believe there's no point in
> trying to declare the package on the nodejs side 'legacy' unless there's a
> committment from upstream to deprecate the /usr/bin/node name.
>
> So from my perspective, the packages would be:
>
> Package: node
> Depends: ax25-node
> Conflicts: nodejs
> -- /usr/sbin/node -> /usr/sbin/ax25-node
>
> Package: ax25-node
> -- /usr/sbin/ax25-node
>
> Package: nodejs
> Conflicts: node
> -- /usr/bin/nodejs
> -- /usr/bin/node -> /usr/bin/nodejs
>
> > So this would need package replacement, which is a pain, and an
> > exception for a policy violation -- is that enough to kill the idea?
>
> I think it's an acceptable compromise under the circumstances.This seems a little one-sided, as it inflicts the bulk of the work on those that are less to blame. It also prevents a HAM from deciding to dabble in Node.js while preserving the 'node' name for their ax25 use. I suppose if the ax25 maintainers think that this counts as a compromise, that's up to them, but I actually rejected something very similar to this while I was formulating my suggestion on the basis that it lacks symmetry and so seems unfair. I don't really see the point of adding the symlink to nodejs if you're not putting it in a separate package -- one of the reasons I had for doing that split was that it might allow us to later provide popcon stats of the proportion's of node.js users that install the symlink package as part of evidence to persuade upstream that it might be worth entertaining a better binary name -- having them both in the same package discards that information. It also fails to draw people's attention to the problem as much as the dual use of -legacy named packages -- N.B. I wasn't expecting those packages to be retired quickly (or perhaps ever). The -legacy was meant to be an attention grabber, and perhaps to reflect a hope that at some point in the future one or both upstreams might switch to a better name. It occurs to me that if we're going to allow this form of conflicts-abuse, we should also insist that no dependencies are allowed on the conflicting packages, to ensure that only the distinct binary names are available for depending packages. If we accept that restriction, then you'd want there to be a separate package for the Node.js symlink, as otherwise no package would be able to declare a dependency on Node.js, which would be inconvenient. Cheers, Phil. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND
pgpK6zIP5aAgO.pgp
Description: PGP signature
