[openstack-dev] [all][packaging] Adding files to /etc in a package
zigo at debian.org
Thu Jul 2 01:24:21 UTC 2015
On 07/02/2015 12:26 AM, Tony Breeds wrote:
> On Wed, Jul 01, 2015 at 01:33:03PM +0200, Thomas Goirand wrote:
>> The file has nothing to do in /usr/share/doc either. By per the debian
>> policy manual: we shouldn't rely on /usr/share/doc, as it can be removed
>> entirely by the users. /usr/share/python-novaclient could be a place,
>> but really, the correct location is
>> /usr/share/bash-completion/completions, not /etc (btw: that's a new
>> thing, it used to be in /etc, but there's now a lintian warning about it).
> Personally I like /usr/share/python-novaclient as that's very deliberatlely
> package centric and if I do that right should make your life as a consumer of
> the python-novaclient git repo a little simplier.
The problem is that this is the *debian* way in *some* case (it doesn't
fit this one where we should put it in
/usr/share/bash-completion/completions), and I don't think it matches
the Red Hat policy at all (Red Hat guys, please speak up!). Again:
please leave this decision to package maintainers, they know better.
> so with that in mind I'm thinking something like:
> packages =
> + data_files =
> + usr/share/python-novaclient/nova.bash_completion = tools/nova.bash_completion
> Note: I typed that in to my mail client so the diff will be malformed
> Note: I deliberatly used 'usr/' rather than '/usr/' so the config file is in
> the install root
> Note: For my development systems I can easily add a symlink like:
> (cd /usr/share/bash-completions/ ; ln -s ../python-novaclient/nova.bash_completion nov
For your development system, as you wrote, you can wget the file from
github. And if that's annoying to do one by one, you can write a script
to do it for all clients at once. Even better: write this inside
devstack. But by all means, fixing your development env isn't a reason
to add cruft to the pbr packaging.
> Note: the subject of this email is now wrong but we get the idea.
> So assuming that somethign like that is acceptable to distribution packages and
> python packagers we're winning :)
Distribution package maintainers would like you to not address it at
all, and just let us manage it in debian/rules, thanks.
> The last questions are:
> - How does pbr handle the case where usr/share/python-novaclient/ dosn't exist ?
> - Can I make is do the equivilent of: mkdir -p $install_root/usr/share/python-novaclient/ somehow?
> - At this point I'll propose a change like this for:
> python-ceilometerclient python-cinderclient python-glanceclient
> python-group-based-policy-client python-heatclient python-ironicclient
> python-keystoneclient python-magnetodbclient python-manilaclient
> python-manilaclient python-mistralclient python-mistralclient
> python-monascaclient python-muranoclient python-muranoclient
> python-neutronclient python-novaclient python-senlinclient
> python-surveilclient python-tackerclient python-watcherclient
Please *don't* !!!
Thomas Goirand (zigo)
More information about the OpenStack-dev