[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Package naming rant

On 04/22/2016 10:47 AM, Enrico Zini wrote:
> I do not know where openstack components install themselves; if they
> install in /usr/bin stuff that is never meant to be run by the command
> line, I think it would be more approriate to jump at the throat of
> openstack upstreams rather than at that of the DDs who packaged it.

All of the things installed in /usr/bin may be run on the shell. Some
are daemons, but traditionally, we install daemons in /usr/bin, so I
don't see how OpenStack is different.

Currently, there's a lot of cli tools using /usr/bin. For example:

These are the clients which the final user is using (to create volumes,
virtual machines, networks or object to store, just to take the examples

Though slowly, this is being consolidated into a single "openstack"
command line. Hopefully, in a year or 2, we'll have all the individual
cli tools all migrated as Python plugins of python-openstackclient.

Now, there's loads of server packages which are dropping daemons within
/usr/bin, like nova-compute, neutron-server, cinder-volume (to stay with
the same examples). I don't believe that this will ever clash with
anything else.

> The package namespace, and the /usr/bin namespeace, are currently flat,
> and flat namespaces[2] work bettter when participants try to keep to
> some level of hygiene, and people who do not make an attempt to
> coordinate with others give a feeling like those who jump the queue at
> the bus stop.

I agree. And I often discussed with upstreams, to make sure we don't
have too generic names in /usr/bin. And upstream has always been
receptive to my recommendations.

> It may be that the right solution is not to have a single namespace, and
> to design things so that you cannot do videogames, openstack and
> biochemistry research on the same system, and if one is not interested
> in openstack/biochemistry/videogames, then one doesn't even get to see
> the openstack/biochemistry/videogames packages and get confused by them.

I'm hoping that the Bikesheds will solve that. It has always been my
intention to push all of OpenStack in there, since the first description
from Ganneff.

Though really, if one day we have a clash with an OpenStack package and
a video game (it's very unlikely, but let's pretend...), I don't think
anyone will care much if we add a Conflicts: and declare they can't be
installed at the same time. As a mater of principle, I'll still try to
solve it in a better way, but still, nobody will really care.


Thomas Goirand (zigo)

Reply to: