Here is a patch to bdist_rpm. It does the following:
Fills in question marks in help
Reads scripts in from files rather than strings
Adds RPM 2 compatibility mode (untested). Use of this mode requires that --bdist-base be specified because bdist_rpm has no way of detecting where RPM wants to find spec files and source files. An unmodified RedHat 5.0 system would require '--bdist-base=/usr/src/RedHat'. (You would also have to be root.) If the rpmrc file has been modified to allow RPMs to be built by normal users then --build-base would need to be changed accordingly.
Formats the changelog.
On 04 June 2000, Harry Henry Gebel said:
Here is a patch to bdist_rpm. It does the following:
Cool, thanks. A few comments...
Reads scripts in from files rather than strings
Then why do the help strings say
--prep-script pre-build script (Bourne shell code) --build-script build script (Bourne shell code) --install-script installation script (Bourne shell code) --clean-script clean script (Bourne shell code) --pre-install pre-install script (Bourne shell code) --post-install post-install script (Bourne shell code) --pre-uninstall pre-uninstall script (Bourne shell code) --post-uninstall post-uninstall script (Bourne shell code)
? My automatic response to those help messages would be
setup.py bdist_rpm \ --post-install="echo 'thanks for installing me" \ --pre-uninstall="echo 'you bastard! how dare you uninstall me?'"
ie., put unadorned shell code into the appropriate "bdist_rpm" options. Now I'm totally confused about the right way to proceed. Considerations:
* you might prefer to write your {pre,post}-{install,uninstall} scripts in Python rather than shell, especially if you'll use the same scripts on non-Unix platforms
* you might have the same scripts for all platforms, or you might have distinct Unix/Windows/Mac OS scripts, or you might even have distinct Debian Linux/Red Hat Linux/Free BSD/NetBSD/Solaris/IRIX/... scripts
* very similar to the above: you might have the same scripts for every type of built distribution, or you might have different ones for RPM, Debian packages, BSD packages, Thomas' homebrew Windows installer, Wise installers, etc.
* you might have very simple, one-command scripts (especially if they are shell code), or complex scripts that need to go in a file
* very rarely would you specify all this on the "bdist_rpm" command line -- this is the sort of stuff that the per-distribution config file (setup.cfg) is just made for
I don't have a ready answer, I just thought I'd bring up these points for anyone who thinks they might. ;-( I'll leave the bdist_rpm code alone for now, since there's no point in overgeneralizing yet.
Adds RPM 2 compatibility mode (untested). Use of this mode requires that --bdist-base be specified because bdist_rpm has no way of detecting where RPM wants to find spec files and source files. An unmodified RedHat 5.0 system would require '--bdist-base=/usr/src/RedHat'. (You would also have to be root.) If the rpmrc file has been modified to allow RPMs to be built by normal users then --build-base would need to be changed accordingly.
Seems reasonable -- probably something you'd set in the site-wide Distutils config file. I'll be sure to give it a workout.
I'll check your patch in shortly...
Greg
On 04 June 2000, I said:
Considerations:
you might prefer to write your {pre,post}-{install,uninstall} scripts in Python rather than shell, especially if you'll use the same scripts on non-Unix platforms
you might have the same scripts for all platforms, or you might have distinct Unix/Windows/Mac OS scripts, or you might even have distinct Debian Linux/Red Hat Linux/Free BSD/NetBSD/Solaris/IRIX/... scripts
very similar to the above: you might have the same scripts for every type of built distribution, or you might have different ones for RPM, Debian packages, BSD packages, Thomas' homebrew Windows installer, Wise installers, etc.
you might have very simple, one-command scripts (especially if they are shell code), or complex scripts that need to go in a file
very rarely would you specify all this on the "bdist_rpm" command line -- this is the sort of stuff that the per-distribution config file (setup.cfg) is just made for
OK, I think I have an answer: for "bdist_rpm", just supply little snippets of shell code. If those snippets are "python /tmp/foo_postinst.py", that's fine. (I'm just guessing that post-installation scripts would go to /tmp, and I have no idea how pre-installation scripts would be handled.)
IOW, I'm inclined to push the complexity onto module developers, packagers, and their config files. I simply don't understand the situation sufficiently to construct an all-singing, all-dancing, pre/post install/uninstall bureaucracy for the Distutils.
Greg
On Sun, Jun 04, 2000 at 10:38:59AM -0400, Greg Ward wrote:
On 04 June 2000, Harry Henry Gebel said:
Reads scripts in from files rather than strings
Then why do the help strings say --prep-script pre-build script (Bourne shell code) --build-script build script (Bourne shell code) --install-script installation script (Bourne shell code) --clean-script clean script (Bourne shell code) --pre-install pre-install script (Bourne shell code) --post-install post-install script (Bourne shell code) --pre-uninstall pre-uninstall script (Bourne shell code) --post-uninstall post-uninstall script (Bourne shell code) ? My automatic response to those help messages would be setup.py bdist_rpm \ --post-install="echo 'thanks for installing me" \ --pre-uninstall="echo 'you bastard! how dare you uninstall me?'"
Good point; the help strings do not do a good job at indicating that a path is wanted. Unfortunately I'm not good at thinking up help strings.
- you might prefer to write your {pre,post}-{install,uninstall} scripts in Python rather than shell, especially if you'll use the same scripts on non-Unix platforms
I will have to ask on the RPM list how people have handled using non-shell scripts; maybe insert the python script into the shell script with `python -c `? (Or `echo | python -`?) Both of these would generate a pretty sloppy looking spec file with lots of escapes (unless the author refrained from quoting with '"' and using the '$' and '' characters), but maybe they are best; sometimes utility wins out over aesthetics. Anyhow I will see how this problem has been handled in the past as I'm sure other people have run into it.
Another thought just occurred to me:
should we default the "requires" list to "python-1.5.2" (or whatever the current Python version is)? Developers can of course override this, but it seems like it might be a useful default.
Greg
On Sun, Jun 04, 2000 at 10:40:50AM -0400, Greg Ward wrote:
should we default the "requires" list to "python-1.5.2" (or whatever the current Python version is)? Developers can of course override this, but it seems like it might be a useful default.
Good question, maybe it would be best to just require python and if the package requires a specific version let the packager override this. On the other hand 1.5.2 has been out for long enough that alot of modules do require it, so maybe "python >= 1.5.2" should be the default.
On 04 June 2000, Harry Henry Gebel said:
Good question, maybe it would be best to just require python and if the package requires a specific version let the packager override this. On the other hand 1.5.2 has been out for long enough that alot of modules do require it, so maybe "python >= 1.5.2" should be the default.
One good argument for requiring Python 1.5.2: if you wish to build/install from source using the Distutils, you need Python 1.5.2.
Yes yes, I know the right place to enforce this is when installing the Distutils themselves. It was just a thought.
Greg
participants (2)
-
Greg Ward -
Harry Henry Gebel