Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi
On 10/01/2013 03:45 PM, Thomas Goirand wrote: Hi, I have just found out that there's already a source package called trove in Debian: http://packages.debian.org/source/sid/trove Lucky, I don't think it will clash with OpenStack trove since it produces libtrove-java* .deb files, though that's quite annoying. The source package for OpenStack Trove will have to be called something like openstack-trove, which isn't nice. Since our ecosystem was already madly in love with codenames when the openSUSE people joined the fun, we went with the openstack-$BLA naming scheme right from the beginning :-) A long history of pain (speak clashes) made us do that for all kinds of things, thus we enforce prefixes like ruby-, python(3)-, go- and java- for whenever it makes sense. BTW. and while you're at it, the same holds true for daemon user names in /etc/passd, we've also had bug reports due to clashes there :-) Also, in PyPi, there is: https://pypi.python.org/pypi/TroveClient which would clash with python-troveclient. This pypi module was uploaded more than a year ago. 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. So, I am really questioning the choice of Trove as a name for the DBaaS in OpenStack. I think it is a pretty bad move. :( Is it too late to fix this? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sascha Peilicke SUSE Linux GmbH, Maxfeldstr. 5, D-90409 Nuernberg, Germany GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer HRB 16746 (AG Nürnberg) signature.asc Description: OpenPGP digital signature ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] trove is already a source package in Debian and a Python module in PyPi
Hi, I have just found out that there's already a source package called trove in Debian: http://packages.debian.org/source/sid/trove Lucky, I don't think it will clash with OpenStack trove since it produces libtrove-java* .deb files, though that's quite annoying. The source package for OpenStack Trove will have to be called something like openstack-trove, which isn't nice. Also, in PyPi, there is: https://pypi.python.org/pypi/TroveClient which would clash with python-troveclient. This pypi module was uploaded more than a year ago. 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. So, I am really questioning the choice of Trove as a name for the DBaaS in OpenStack. I think it is a pretty bad move. :( Is it too late to fix this? Cheers, Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi
On Oct 1, 2013, at 6:45 AM, Thomas Goirand wrote: Hi, I have just found out that there's already a source package called trove in Debian: http://packages.debian.org/source/sid/trove Lucky, I don't think it will clash with OpenStack trove since it produces libtrove-java* .deb files, though that's quite annoying. The source package for OpenStack Trove will have to be called something like openstack-trove, which isn't nice. Also, in PyPi, there is: https://pypi.python.org/pypi/TroveClient which would clash with python-troveclient. This pypi module was uploaded more than a year ago. 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. So, I am really questioning the choice of Trove as a name for the DBaaS in OpenStack. I think it is a pretty bad move. :( Is it too late to fix this? Well this sucks. Im not sure im a fan of renaming it because of the previous existence of a package. Renaming is not fun. Ill let the more experienced openstack peoples help decide on this... 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
Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi
On 10/1/2013 10:53 AM, Michael Basnight wrote: Well this sucks. Im not sure im a fan of renaming it because of the previous existence of a package. Renaming is not fun. Ill let the more experienced openstack peoples help decide on this... Certainly it's not fun, but wouldn't it be easier to do it NOW, rather than later? Nick ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi
On Oct 1, 2013, at 8:00 AM, Nicholas Chase wrote: On 10/1/2013 10:53 AM, Michael Basnight wrote: Well this sucks. Im not sure im a fan of renaming it because of the previous existence of a package. Renaming is not fun. Ill let the more experienced openstack peoples help decide on this... Certainly it's not fun, but wouldn't it be easier to do it NOW, rather than later? Hah, well, it begs the question, why are we _not_ namespacing all openstack packages. If you look @ the rpms, they are all namespaced [1]. IMHO, i wouldnt mind seeing openstack-blah packages. And let me reiterate, im not sure changing our name _again_ is the way to go because of a conflicting debian package. This wont be a problem for the rpms, because they are namespaced (openstack-trove). [1] https://admin.fedoraproject.org/pkgdb/acls/name/openstack-nova 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
Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi
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?
Ask ftp masters to reject the package and re-upload with the source
package renamed to have an openstack prefix/suffix/infix.
Thanks but no thanks. I need to have the python namespace (eg, the
egg-info and such) to match the package name, otherwise there will be no
correct automatic ${python:Depends} substitution.
FYI, the message was more addressed to the OpenStack community, rather
than -devel...
On 10/01/2013 10:53 PM, Michael Basnight wrote:
Well this sucks.
Indeed!
Im not sure im a fan of renaming it because of the
previous existence of a package.
Well, I wonder how the Trove name was chosen. Clearly, it was done
without any good policy in place.
Renaming is not fun.
It sure isn't. Quantum - Neutron was hell for everyone. Though luckily,
Trove isn't that big (yet).
Ill let the more experienced openstack peoples help decide on this...
Same over here. Though for this not to happen again, I think the
OpenStack projects needs to set some rules for project name choice.
Thomas
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi
On 10/01/2013 11:23 PM, Michael Basnight wrote: On Oct 1, 2013, at 8:00 AM, Nicholas Chase wrote: On 10/1/2013 10:53 AM, Michael Basnight wrote: Well this sucks. Im not sure im a fan of renaming it because of the previous existence of a package. Renaming is not fun. Ill let the more experienced openstack peoples help decide on this... Certainly it's not fun, but wouldn't it be easier to do it NOW, rather than later? Hah, well, it begs the question, why are we _not_ namespacing all openstack packages. If you look @ the rpms, they are all namespaced [1]. IMHO, i wouldnt mind seeing openstack-blah packages. And let me reiterate , im not sure changing our name _again_ is the way to go because of a conflicting debian package. This wont be a problem for the rpms, because they are namespaced (openstack-trove). [1] https://admin.fedoraproject.org/pkgdb/acls/name/openstack-nova Because the problem is *not* only within the Debian package naming. They are tight together. The problem is that dh_python2 uses (IMO nicely) the Python namespace to generate dependencies automatically. If we start pre-fixing package names, then all sorts of tricks will have to be added, like debian/pydist_override files and so on, so that we get the correct python-openstack-NAME package and not python-NAME. So if you want to prefix things, that's a very good idea, but then the Python namespace has to also include this prefix (for example, we would have python-openstack-troveclient as package name, and openstack-troveclient in the Python namespace). Thomas Goirand (zigo) ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi
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-NAMEsearchon=namessuite=allsection=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
Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi
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-NAMEsearchon=namessuite=allsection=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
Re: [openstack-dev] trove is already a source package in Debian and a Python module in PyPi
On 10/01/2013 01:40 PM, 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. Thank you! 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). Whee. That's lovely. 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? This: https://pypi.python.org/pypi/python-troveclient Is us - so we append a python- anyway. Don't ask me why - we just always have. 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-NAMEsearchon=namessuite=allsection=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
