On 09/28/2017 04:50 PM, Jesse Pretorius wrote: > There’s some history around this discussion , but times have changed > and the purpose of the patches I’m submitting is slightly different  > as far as I can see – it’s a little more focused and less intrusive. > > > > The projects which deploy OpenStack from source or using python wheels > currently have to either carry templates for api-paste, policy and > rootwrap files or need to source them from git during deployment. This > results in some rather complex mechanisms which could be radically > simplified by simply ensuring that all the same files are included in > the built wheel. Distribution packagers typically also have mechanisms > in place to fetch the files from the source repo when building the > packages – including the files through pbr’s data_files for packagers > may or may not be beneficial, depending on how the packagers do their > build processes. > > > > In neutron , glance , designate  and sahara  the use of the > data_files option in the files section of setup.cfg is established and > has been that way for some time. However, there have been issues in the > past implementing something similar – for example in keystone there has > been a bit of a yoyo situation where a patch was submitted, then reverted. > > > > I’ve been proposing patches  to try to make the implementation across > projects consistent and projects have, for the most part, been happy to > go ahead and merge them. However concern has been raised that we may end > up going through another yo-yo experience and therefore I’ve been asked > to raise this on the ML. > > > > Do any packagers or deployment projects have issues with this > implementation? If there are any issues, what’re your suggestions to > resolve them?
I still have the issue that adding stuff in etc, at packaging time, push them in /usr/etc, which is obviously wrong. We tried to push for a PBR patch, but failed, as Robert Collins wrote it had to be fixed in setuptools. Which is why all patches have been reverted so far. While I may agree with Robert, I think we had to choose for a pragmatic (even temporary) solution, and I don't understand why it's been years that this stays unfixed, especially when we have an easy solution.  So, until that is fixed, please do not propose this type of patches. Cheers, Thomas Goirand (zigo)  https://review.openstack.org/#/c/274077/ __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev