[openstack-dev] [neutron][general] Multiple implementation of /usr/bin/foo stored at the same location, leading to conflicts

Thomas Goirand zigo at debian.org
Wed Jun 22 11:58:02 UTC 2016

tl;dr: Please don't reuse multiple times /usr/bin/neutron-l3-agent,
instead call it /usr/bin/neutron-fwaas-l3-agent, as otherwise it makes
it impossible for dpkg to install neutron-fwaas, and downstream distros
must patch & hack.


I've seen more than once the same file on /usr/bin/foo in different
Neutron implementation. For example, neutron-fwaas reimplements

While a reimplementation is probably a good idea and a nice feature,
having the exact same binary name is wrong. Let me explain why.

Since we may want to support multiple version of Python at some point
(ie: Py2 vs Py3), then all files in /usr/bin have to be installed in the
python-neutron package or python3-neutron package (the later doesn't
exist *yet*, but will soon, when I have time to implement the support
for Py3).

The way to do it for distributions (at least, that's the way I do), is
to rename /usr/bin/foo as /usr/bin/python2-foo in the python-foo
package, and /usr/bin/python3-foo in the python3 package. Then the
.postinst script calls "update-alternatives" with different priorities,
and then /usr/bin/foo is created as a symlink to /usr/bin/python2-foo.

Therefore, the files in /usr/bin/* are *NOT* installed on the package
which contains the init script starting the daemon. Something like
neutron-fwaas (which will also at some point also support the same
mechanism mentioned above with update-alternatives) will also attempt to
install /usr/bin/python2-foo and /usr/bin/python3-foo, which is of
course refused by dpkg.

So, the solution, for something like neutron-fwaas, is to ship
/usr/bin/neutron-fwaas-l3-agent instead of /usr/bin/neutron-l3-agent.
These, installed in the python-neutron-fwaas will not clash with the
binaries from python-neutron.

While all of the above can be implemented at a distribution level, I am
convince that it'd be nicer if it was also considered upstream.

Note that I am hereby talking for Debian & Ubuntu. I don't know the
situation in the RPM world, but I suspect they will have the same kind
of issues.

Thoughts welcome,

Thomas Goirand (zigo)

More information about the OpenStack-dev mailing list