Excerpts from Thomas Goirand's message of 2017-10-10 21:28:35 +0200: > On 10/10/2017 01:21 PM, Jesse Pretorius wrote: > > > > > > On 10/10/17, 12:08 PM, "Jesse Pretorius" <jesse.pretor...@rackspace.co.uk> > > wrote: > > > >> $ python setup.py install --skip-build --root /tmp/keystone > >> --install-data / > > > > Apologies – I copied the wrong command, it should have been: > > > > $ python setup.py install --root /tmp/keystone --install-data / > > Isn't it that "--install-data" carries a different meaning than config > files? To me, its semantic was data files, not config files. Which leads > me to the idea that "data_files" in setup.cfg is probably the wrong way > to describe config files. Typically, in distros, we'd have data files > (for example, timezone data, pictures, docs, etc.) in /usr/share, while > config files lives in /etc. Aren't we here mixing 2 concepts? > > For example, if we take openstack-doc-tools's setup.cfg, it has under > data_files: > > data_files = > share/openstack-doc-tools/sitemap = sitemap/* > share/openstack-doc-tools/cleanup = cleanup/* > > Typically, for openstackdocstheme, I'd prefer these files to end up under: > > /usr/lib/python2.7/dist-packages/openstackdocstheme > > (sed s/2.7/3/ if using Python 3) > > With your method, wouldn't these files end up in the wrong location, ie > outside of /usr? What if openstackdocstheme has both config files and > "real" data files? > > Probably, we need a method to handle both cases: config files and data > files. In fact, don't think PBR's data_files is designed for handling > config files at all. Which is the very reason why I think it's broken to > use it the proposed way.
It seems to me that *sample* configuration files should be treated as data files and not configuration files. A package might include several sample configuration files, but only one of those should be used (if any are). Doug > > Cheers, > > Thomas Goirand (zigo) > __________________________________________________________________________ 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
