On Thu, Nov 03, 2016 at 01:32:14PM +0100, Paolo Greppi wrote: > cmdtest provides yarn since this commit: > http://git.liw.fi/cgi-bin/cgit/cgit.cgi/cmdtest/commit/?id=859bb5ba9631df883dd7b074ff649ea2ca76e1ad Yep, in 0.27-1, uploaded Sep 21 this year. cmdtest has included the yarn program since June, 2013. I added that because people kept having trouble finding the package when they want to install (my) yarn. > A package search for yarn currently returns no match. > https://packages.debian.org/search?keywords=yarn I assume that's because it's a Provides, and not an actual package name. I haven't created a separate yarn package to avoid making the FTP masters from processing another package in NEW. > The real issue here is that both cmdtest and the proposed package > install a yarn binary. I don't think that's the only reason, I think the package name conflict is also an issue. But you're right that the binary name conflict also needs be resolved. > 1. as you suggest, renaming this package and the binary it installs to > yarnpkg Yes, please. :) > 2. keeping the package name yarn but renaming the binary to yarnpkg I don't see why you'd call the package yarn. There would be a conflict with the yarn name that cmdtest provides. > 3. renaming the executable yarn in cmdtest to yarn-something-else, and > have cmdtest provide yarn-something-else It's been called yarn in the cmdtest package for years. I'd prefer to not rename it, thanks. It's a name that's dear to me, has some pleasant memories associated with it, and that I've gotten used to. The JS package manager called yarn is quite new. It wouldn't be unreasonable to suggest to them to rename it to avoid a naming conflict, in my opinion. > 4. ignoring the conflict and setting the Conflict flags in both packages > (https://www.debian.org/doc/debian-policy/ch-relationships.html#s-conflicts) I don't think this is acceptable at all. There's no reason for these two packages to conflict. There's no reason why we'd prevent someone from installing both at the same time. > For 3, there could be a cmdtest-legacy package for those who do not use > yarn/yarnpkg and like to invoke the yarn binary in cmdtest as yarn > rather than yarn-something-else. Oh dear, please no. This is just insane. A whole bunch of work with no actual benefit. It just makes things more complicated for everyone. > At the moment we are confusing the newbies who come to Debian for > JavaScript development. I understand. I admit that I don't much care. Having to learn that it's called yarnpkg in Debian, yarn on MacOS, and maybe something else somewhere else seems not too big a deal to me. It's a very minor difference compared to the churn in the Javascript ecosystem. > It would be easier if they could apt-get install node/yarn and then just > type node/yarn to use them. Traditionally in Debian, we've handled naming conflicts by giving a name to the first package using it. There have been exceptions of course: node, and git come to mind. Some of these conflicts have been solved by decree by the FTP masters, a couple by the technical committee. Many have been resolved amicably by the Debian package maintainers. Let's aim for that in this case. I don't know of any cases when naming conflicts in Debian have been solved by having a duel at Debconf. It's nearly a year to the next Debconf, which is probably too long for solving this. Also, I've lost my lightsabre. We in Debian will always have naming conflicts like this, as long as we have a flat namespace for packages (or in /usr/bin). It doesn't help when upstreams don't do sufficient due diligence when choosing names, meaning that we need to resolve them in Debian. > - cmdtest has ~50 It's not a particularly popular package. I make no claim of popularity, only of having used the name first. > - for yarn/yarnpkg it's difficult to predict now, but probably it will > end up in the range 0-6000, high or low depending how much traction it > will get. I don't think that is implausible. I'm not sure it's important, though. > In conclusion, I leave it to those who know more what is the best thing > to do ! Well, my opinion is still that it'd be nice if you called both the package and binary yarnpkg. That would be a very simple, easy solution. If you can convince upstream to also call the binary yarnpkg (or yarnjs, or some other variant), that would be even better. -- I want to build worthwhile things that might last. --joeyh
Attachment:
signature.asc
Description: PGP signature