[openstack-dev] [all][packaging] Adding files to /etc in a package

Thomas Goirand 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:
> ---
>  [files]
>  packages =
>      novaclient
> + data_files =
> +     usr/share/python-novaclient/nova.bash_completion = tools/nova.bash_completion
> ---
> Note[1]: I typed that in to my mail client so the diff will be malformed
> Note[2]: I deliberatly used 'usr/' rather than '/usr/' so the config file is in
>          the install root
> Note[3]: 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[4]: 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* !!!

Cheers,

Thomas Goirand (zigo)




More information about the OpenStack-dev mailing list