On Sun, 6 May 2012 10:29:18 -0700, Steve Langasek <vorlon@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
Attachment:
pgpvA9LcMNJdr.pgp
Description: PGP signature