On 09/28/2017 04:50 PM, Jesse Pretorius wrote: > There’s some history around this discussion [1], but times have changed > and the purpose of the patches I’m submitting is slightly different [2] > 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 [3], glance [4], designate [5] and sahara [6] 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 [7] 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. [1] So, until that is fixed, please do not propose this type of patches. Cheers, Thomas Goirand (zigo) [1] 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
