On 04/21/2016 08:08 PM, Gunnar Wolf wrote:
> Thomas Goirand dijo [Thu, Apr 21, 2016 at 06:46:47PM +0200]:
>> In the general case, I'd agree. But we're not talking about "a package"
>> here, but about a complete *suite* of a complex cloud system.
>>
>> The argument is that you can't use OpenStack without at least learning
>> what the components are, which makes it pointless (and in fact very
>> annoying) to prefix them with openstack-. I'd say it take at least a
>> month to understand all the interactions.
>>
>> Now that there's the suite::openstack on all of these packages, it will
>> be a lot easier to search anyway. Also, I take a great care about the
>> short descriptions.
>
> Supporting what I understand from Ian's, Aigars' and Enrico's points,
> we have many aeas where the area of application for a package is
> encoded in the package name itself. We have (according to "apt-cache
> search") 1011 packages starting with "ruby-", 3566 conforming with
> "lib.*-perl", 3173 starting with "python-", and even for newcomers,
> 451 starting with "golang-". And some of them do have quite deep names
> (which have been argued against repeatedly for different reasons),
> such as (five longest for each):
>
>
> ruby-rails-assets-jeresig-jquery.hotkeys
> ruby-rails-assets-jquery-fullscreen-plugin
> ruby-rails-assets-jakobmattsson-jquery-elastic
> ruby-rails-assets-markdown-it-diaspora-mention
> ruby-rails-assets-markdown-it--markdown-it-for-inline
>
> libbusiness-onlinepayment-transactioncentral-perl
> libcatalyst-action-serialize-data-serializer-perl
> libplack-middleware-fixmissingbodyinredirect-perl
> libcatalyst-authentication-credential-authen-simple-perl
> libcatalyst-plugin-authentication-credential-openid-perl
>
> python-xstatic-jquery.bootstrap.wizard
> python-sphinxcontrib.programoutput-doc
> python-fedmsg-meta-fedora-infrastructure
> python-zope.component-persistentregistry
> python-djangorestframework-fsm-transitions
>
> golang-github-hashicorp-go-immutable-radix-dev
> golang-github-hashicorp-net-rpc-msgpackrpc-dev
> golang-github-hydrogen18-stoppablelistener-dev
> golang-github-cyberdelia-go-metrics-graphite-dev
> golang-github-shurcool-sanitized-anchor-name-dev
>
> Even more, querying from the 50665 my apt-cache knows about, without
> discrimination of any kind, the ten longest are:
>
> $ apt-cache search .|cut -f 1 -d \ |perl -e '@data = sort {length($a)<=>length($b)} <>; print @data[-10..-1]'
> libbusiness-onlinepayment-transactioncentral-perl
> libcatalyst-action-serialize-data-serializer-perl
> libplack-middleware-fixmissingbodyinredirect-perl
> libmono-system-reactive-observable-aliases0.0-cil
> libmono-system-componentmodel-dataannotations4.0-cil
> ruby-rails-assets-markdown-it--markdown-it-for-inline
> libmono-system-windows-forms-datavisualization4.0a-cil
> libcatalyst-authentication-credential-authen-simple-perl
> libcatalyst-plugin-authentication-credential-openid-perl
> libmono-system-runtime-serialization-formatters-soap4.0-cil
>
> So, in all fairness, looking at the longest-named packages mentioning
> Openstack:
>
> $ apt-cache search openstack|cut -f 1 -d \ |perl -e '@data = sort {length($a)<=>length($b)} <>; print @data[-5..-1]'
> python-sphinxcontrib-docbookrestapi
> python-sphinxcontrib.docbookrestapi
> golang-github-rackspace-gophercloud-dev
> fusiondirectory-plugin-openstack-compute
> fusiondirectory-plugin-openstack-compute-schema
>
> Adding 'openstack-' somewhere in their package name won't hurt users
> too much.
You're comparing applications and libraries, IMO, that's not relevant.
It's natural to add "python" for python libs, you're even kind of forced
to do it by the way dh_python{2,3} are working. But for application,
it's best to just keep what upstream uses.
FYI, Red Hat decided to prefix everything with openstack-, so we have
things like: openstack-neutron-plugin-linuxbridge-agent. Users don't
like it at all.
Last, I'm not alone here. If we were to rename all OpenStack packages
for services, then this would break all the compatibility with the
puppet-openstack manifests, which are working for both Debian and
Ubuntu. I really don't want to do that, Quite the opposite: I'm making
efforts so that packages in Ubuntu and Debian are at least close, so
that there's not too many differences to handle. Already, there's
special cases for Neutron, Nova and Horizon, as they are slightly
different in Ubuntu and Debian.
Could we have this discussion in the OpenStack PKG list instead? It
doesn't feel like this list is the appropriate one. I also don't believe
that any of the people writing in this thread are OpenStack users, are
you guys?
Cheers,
Thomas Goirand (zigo)