Open Stack

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&section=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.