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
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
