[Distutils] stdeb-0.3 error

[Gerry Reno]

Andrew Straw wrote:
> 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.
>   
Yes, looking back you are right.  I didn't find it with apt-get and had 
to use easy_install to get it (which I don't normally do).
$ sudo easy_install --upgrade stdeb
says stdeb 0.3 is best match and already installed.  How do I get stdeb 0.4?


>   
>>> 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.
>
>   
For bdist_rpm the way that you get pre and postpackage install scripts 
to run during package install is by using
the following in the setup.cfg:
[bdist_rpm]
install_script = rpm_install_sh.txt

then rpm_install_sh.txt gets inserted into the rpm .spec file at the 
%install marker.  Now you can also add other sections into 
rpm_install_sh.txt like %pre and %post which are sections of shell 
scripts that run prepackage and postpackage install.  As far as 'python 
setup.py install' build type pre/postinstall, you can subclass install 
class and just run some scripts either side of parent "install" class.


Regards,
Gerry