On 12 June 2016 at 11:31, Thomas Goirand <z...@debian.org> wrote: > On 06/11/2016 05:02 AM, Robert Collins wrote: ... > Then keystone.conf ends up installed in /usr/etc/keystone when setup.py > install is used. With this configuration, it would be installed > correctly within a venv.
Except that noone uses 'setup.py install' - *except* for rpm and dpkg packagers. Everyone else uses pip, and pip won't pass new options. Worse, pip creates wheels and then installs the wheels, and until PEP 491 [1] is finalised and implemented, wheels won't change their behaviour. > If instead we have: > [files] > data_files = > /etc/keystone/keystone.conf = etc/keystone.conf.sample > > [ notice the leading / for the destination... ] > > Then keystone.conf gets installed on the root of the filesystem instead > of properly be installed within the venv. Though it's installed properly > for distributions in /etc/keystone. > > To address this problem, Julien Danjou attempted to add a --sysconfdir > option in PBR. Though it was rejected by Robert, who wrote in the code > review that it should be addressed within setuptools or disutils. Not should. Must be. A local change to pbr won't solve the problem, except for the very narrow case of package creators (who already have excellent tools - its a single one-line file to fix it on Debian, and I presume roughly the same on RPM distributions). It certainly won't solve it for virtual envs. > If I got the above facts wrong, feel free to let everyone know. Now, my > reply to Robert... > === End of context === > > Robert, > > I do not agree that we *must* wait until politics are discussed and a I'm going to quote what I said back in February - 4 months ago: "Ok, so here's where I got to: - wheel doesn't support or understand /etc per se - setuptools and distutils disagree on the meaning of data files paths - wheel takes the distutils value today - pep 491, which seems moribund, is an attempt to explicitly support sysconf dir's like /etc, and thats what is needed in general. I think the way forward to get this available as a sensible, supportable feature is to discuss it on the distutils-sig list, and that community can help figure out a design, including the backwards compat implications." I don't -2 lightly, and I did considerable research into this patch before leaving the -2 in place. With regards to politics and consensus in the upstream packaging community - well, it would move faster if folk who are distro folk and thus want to see the mess sorted were collaborating there: its been 4 months since Julien's original patch and no discussion has taken place, nor has anyone volunteered in that community to do the work. Its not super hard, and I'd be happy to guide anyone interested in reviving PEP 491 (or drafting an alternative). What I'm not interested in doing is adding an ineffective hack to pbr which we'll have to maintain for an extended period, which isn't actually in pbr's domain (pbr exists to prevent duplication amongst OpenStack projects and provide solid and sane policy, not to replace wheel and setuptools). I'm sorry if that sounds like a hard line, but we had an ongoing series of bugs in pbr - the gift that keeps on giving - from the previous attempts to work around defects upstream of pbr rather than fixing those defects directly, which is a much better strategy : less cost, less technical debt, benefits the entire community, gets better outcomes. -Rob [1]: https://www.python.org/dev/peps/pep-0491/ __________________________________________________________________________ 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