[Distutils] stdeb-0.3 error

[Andrew Straw]

Gerry Reno wrote:
> Andrew Straw wrote:
>> Gerry Reno wrote:
>>  
>>> In my setup.py I have my own "install":
>>>
>>> from distutils.command.install import install
>>> ...
>>> class myinstall(install):
>>> ...
>>>
>>> and when we call dpkg-buildpackage this local "install" seems to maybe
>>> be causing the problem with the error: option
>>> --single-version-externally-managed not recognized.
>>>
>>> How can we make this option be recognized? Do we need to inherit
>>> something from setuptools?
>>>     
>> I think there are 2 options:
>>
>> 1) upgrade to the nascent stdeb 0.4. It doesn't call setup.py with the
>> --single-version-externally-managed argument.
>>   
> I'm using Ubuntu 8.0.4 LTS Server and when I run apt-get it brings in
> stdeb 0.3.  I always use the distro packagers to install software so
> how can I use apt-get to install stdeb 0.4?

stdeb isn't in the Ubuntu (or Debian) repository. And I thought you said
you used easy_install on it. Are you sure you can't just upgrade by
hand? I can't see how else you got it.

>
>> I would suggest option 1. If you need me to make a release, I'm happy to
>> do so -- but maybe that will be better after it has bdist_deb? :)
>>   
> My only concern now with stdeb adding the bdist_deb command is that it
> may not work like other 'bdist' commands.  And having 'bdist_deb' work
> similar to 'bdist_rpm' is important.  It would have to use setup.cfg
> for config and allow for pre/postinstall scripts to run.

Well, to produce the final .deb file, stdeb produces a source package
and then, in another process, calls the debian machinery may be called
to produce the .deb file (I guess you're now quite familiar with that).
I feel this approach benefits from using the standard Debian
infrastructure. Specifically, python-support and debhelper 7 called by
stdeb 0.4 do things like: install a single copy of the .py files and
symlink them into the per-version directories, compile .pyc files
per-version at install time, compile extension modules per-version at
build time, and so on. Reproducing that would be hard, error prone, and
a pointless duplication of effort. And .debs that don't do all that
stuff that will be sub-standard and won't behave like those downloaded
from the Debian/Ubuntu repos. Thus, I really think calling the real
Debian machinery is the way to go.

As I understand it (which is not well), bdist_rpm calls out to an "rpm"
command from the original "python setup.py bdist_rpm" process, but at
that point the binary is already made at this is just a packaging step.

With stdeb, the initial output will be the source package which would be
compiled to a binary by another process -- a subprocess of
dpkg-buildpackage. You can control this binary generation by modifying
debian/rules, which is a Makefile that is run to build the binary. So
you can make sure that building the binary as done by the debian/rules
file handles the options in setup.cfg. It should do that automatically,
since what happens is a glorified "python setup.py install".

As far as pre/postinstall scripts -- what do you need them to do? It
would be possible to add support for stdeb to run these scripts at
debian .deb install time. (stdeb already runs a preinstall script to
ease the python-central -> python-support transition. See commit
9faaf049.) But if they're limited in scope and merely modify the files
you want installed, they're probably already run as part of the .deb
build process if you've hooked into the "install" command.

I can't see how an infrastructure based only on extending the distutils
install command could be used to distinguish between A)
"pre/post-install" scripts that merely modify the files to be installed
and could thus be run at package build time versus B) pre/post-install
scripts that actually need to be run once the .deb package is being
installed on the target system that might do something like start a web
server. It seems there has to be a specification of the difference.

-Andrew