[openstack-dev] [packaging][all] Sample Config Files in setup.cfg

Luigi Toscano ltoscano at redhat.com
Mon Oct 9 09:20:37 UTC 2017

On Saturday, 7 October 2017 12:30:54 CEST Thomas Goirand wrote:
> On 10/03/2017 03:07 PM, Luigi Toscano wrote:
> >> Why not? Simply because installing config files in /usr/etc is silly.
> >> The question would rather be: why not accepting the PBR patch...
> > 
> > It is silly, but again, people consuming from deb or RPM won't notice it.
> Though people doing the packaging will suffer. Please don't throw the
> baby over the wall, and let's fix the issue.

This is an overstatement (proof below). Nothing is different for people doing 
the packaging.

For example, sahara have been installing those files for a long time under 
data_files, When the patch changed the location from /usr, I just changed the 
way those files are copied:
(this does not happen for Ubuntu and Debian packaging right now, so there are 
duplicated files).

This means that:
1) if the files are not installed through data_files, you have to manually 
copy them using the packaging script ;
2) if the files are installed using data_files, you either move them in the 
right position or delete that copy and still copy the proper files in the 
right place

You need to act anyway. So the 2 cases are not different, and point 2) is 
*already happening* for a long while. No change here.

The only difference is that when data_files installation is fixed, it would be 
fixed for everyone, and it's easier to track those file anyway.

> > Sure, having the python tools install the files in the right directory is
> > the ideal final solution.
> Let's get there then. In the mean while, don't break stuff.

Nothing is broken, see above.

> > My point is that the proposed solution is not worse than
> > the previous one and fixes at least one use case that was not previously
> > covered (the one that can be easily fixed).
> You are proposing to induce pain to everyone doing packaging, just
> because it solves your developer pip use case. That's not what OpenStack
> used to do, and that's not fair. Let's fix things properly *first*
> please, maybe by discussing the PBR fix I linked to. Can we agree that
> this is the pragmatic easy (but maybe temporarily) way to fix the issue,
> even if it's not perfect and a setuptools fix would be better?

It does not, see above.


More information about the OpenStack-dev mailing list