Open Stack

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&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.
> 
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131001/003260b3/attachment.pgp>