[openstack-dev] [all][packaging] Adding files to /etc in a package
sean at dague.net
Mon Jul 6 10:48:09 UTC 2015
On 07/02/2015 03:59 AM, Thomas Goirand wrote:
> On 07/02/2015 05:51 AM, Robert Collins wrote:
>> On 2 July 2015 at 13:26, Thomas Goirand <zigo at debian.org> wrote:
>>> On 07/02/2015 02:07 AM, Tony Breeds wrote:
>>>> On Wed, Jul 01, 2015 at 11:07:30PM +0000, Perry, Sean wrote:
>>>>> BTW, see dh_bash-completion from the debhelper package. When in doubt about packaging on a deb based distro look at the debhelper tools source (which is perl).
>>>>> -----Original Message-----
>>>>> From: Perry, Sean
>>>>> Sent: Wednesday, July 01, 2015 4:04 PM
>>>>> To: OpenStack Development Mailing List (not for usage questions)
>>>>> Subject: RE: [openstack-dev] [all][packaging] Adding files to /etc in a package
>>>>> According to Debian standards (which Ubuntu follows mostly) if a package
>>>>> ships bash completion information that file belongs in /etc/bash_completion.d
>>>>> with a file named after the package. You can look in that dir on an
>>>>> Ubuntu/debian box and see the setup.
>>>> Right, but I'm talking about python packaging. Which is certainly closely
>>>> related to system/distribution packaging, but lacks a lot of the machinery
>>>> to get it right.
>>> Correct. Python packaging is made for packaging ... python! Not
>>> configuration files and other system bits.
>> I'm with you there. BUT. Python programs use configuration files. And
>> Python programs provide daemons. Its entirely reasonable and expected
>> within the context of a given program that 'sudo make install' or
>> 'sudo setup.py install' or <...> any number of variations should make
>> the program be usable by all users of the system that its installing
>> it into.
>> I'm going to presume we agree on that in the rest my reply. You may
>> want to stop here if we don't agree about that.
> We do agree. The issue being that there's no universal way to do things,
> and different policy depending on the unix vendor and the way package is
Right, so ideally under such a situation the python installer would
allow for override of logical constructs, which could just be set in a
debian/control or spec file.
Perl actually has a quite good model here with their install toolchain -
I think the crux of the problem is that python installers are not system
aware at all. They assume they are only libraries and scripts, and the
moment it gets more complicated than that the python install toolchain
just shrugs and passes the buck. :( It would be really nice to get away
from that so that.
BASH_COMPLETION_DIR=... python setup.py install
Would be the user experience to get things into a specific directory.
Realize, this is a much larger effort to teach python installation tools
about more than LIB and BIN, which is all they understand today.
More information about the OpenStack-dev