Thx for getting this squared away zigo!! On Oct 1, 2013, at 10:40 AM, Thomas Goirand wrote:
> Hi, > > First of all, before I reply, I'd like to tell that hopefully, I believe > we're fine in this specific case (at least on the Debian side of > things). Though it really shouldn't have happen, and I believe it's my > role to warn everybody about the risks. > > On 10/02/2013 12:02 AM, Monty Taylor wrote: >> >> >> On 10/01/2013 11:45 AM, Thomas Goirand wrote: >>> On 10/01/2013 10:02 PM, Jonathan Dowland wrote: >>>> On Tue, Oct 01, 2013 at 09:45:17PM +0800, Thomas Goirand wrote: >>>>> Since I have already uploaded python-troveclient (currently waiting in >>>>> the FTP master's NEW queue), OpenStack troveclient will be in Sid, but >>>>> if some day, someone wants to upload TroveClient from >>>>> http://dev.yourtrove.com, then we have a problem. >>>> … >>>>> Is it too late to fix this? >> >> I don't think it's a problem. Two reasons: >> >> a) libtrove-java having its source package named trove is a bug. the >> upstream project is called trove4j, that's what their source package >> should have been called. We can't be held accountable for that. > > The source package name isn't a problem, it can be anything. I think I > will use openstack-trove. By the way, it's only "trove4j" because there > was "trove3" before, if I understand well (I get that doing "apt-file > search trove" on my Sid box). > >> b) We got to python-troveclient first. We win. (sorry that's rude, but >> we _did_ get into the queue first. That's the reason that pip is >> "python-pip" in debian, because there is a pip tool in perl. TroveClient >> released last january and dev.yourtrove.com is unresponsive. > > Yes, that might be right for the Debian package. Though at PyPi, there's > TroveClient already. Or is it that PyPi is case sensitive, and then we > don't have a problem here? > >> I DO agree that we need to be careful with them, and I think that a fair >> list of things to check when looking for a name are: >> >> PyPI >> Launchpad >> debian >> fedora > > Please also add Gentoo to the list (since there is also an ongoing > effort to package OpenStack there as well). > >> We might need some follow up from fedora and debian folks about HOW >> people should search for names and what things should be considered in >> conflict. > > For Debian: > > 1/ apt-cache search PACKAGE-NAME > 2/ > http://packages.debian.org/search?keywords=PACKAGE-NAME&searchon=names&suite=all§ion=all > 3/ apt-file search PACKAGE-NAME > 4/ http://www.debian.org/devel/wnpp/being_packaged > 5/ http://www.debian.org/devel/wnpp/requested > > This might not be an exhaustive list of checks. > > And obviously, your favorite search engine might help (avoiding > trademark, as everyone know, is also very important). In this case, it > shows a few results that aren't engaging, and ... nothing about > OpenStack trove. > > Also, while using apt-file search, make sure that no file in /usr/bin is > in conflict. Just to let everyone understand, allow me to remind > everyone the NodeJS which used /usr/bin/node, while an amateur radio > AX25 server "node" source package used /usr/sbin/node. Then we had this > decision from the technical committee: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=614907#113 > > As a result, since NodeJS never migrated to Testing before the freeze > date (and that is a requirement), we released Wheezy without NodeJS. > > This kind of disaster scenario should be avoided at all costs. Note that > within Debian, there's no "this package is more important than this one" > kind of things, so I don't believe that OpenStack would have any > priority in this kind of case, so it is very important to get things right. > >> Remember that most of our 1200 devs do not have any idea how >> debian packaging works. Those of us who _do_ need to give very short and >> succinct guidelines, such as: >> >> The package name should not conflict with source or binary package names >> in Debian. You can search for those by ... > > Well, not only the binary package names (for the source package, it > maters a lot less, we can use anything). What's even more important is > that we should never have *installed files* collision. Declaring a > Breaks: or a Conflicts: doesn't cut it, unless we have 2 implementations > of the same things, with the same functionality (for example mawk vs > gawk, in which case we can use update-alternatives (see manpage)). For > example, if one day someone wants to package the TroveClient from > dev.yourtrove.com, we have such unsolvable problem of file collision (in > the Python dist-packages folder). > >> However, again, in this case I think it's fine, and I do not think we >> need to rename trove beceause there happens to be a package called trove4j. > > I just hope so as well. > > Thomas Goirand (zigo) > > P.S: I will use openstack-trove as source package. > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
