Guido and I have, for a while, been having some discussions about the Python RPMs. He suggested that I bring the topic up here for further discussion. One of the biggest things that we've discussed is that of the naming of the resultant Python. With the 2.1 releases, I started installing the latest stable Python as /usr/bin/python2, so as not to conflict with the Red Hat 1.5.2 version installed in /usr/bin/python (which many of the system tools require). For test releases, I've been using the full release name as the extension, /usr/bin/python2.2c1 (or was it just python2.2?). This is so that multiple versions can be installed 1.5.2, 2.1, 2.2c1... I know there are some other things brought up, but I can't remember them off hand. If it weren't for hackingsociety.org, I probably wouldn't have *ANY* time to work on community projects this month... So, first of all, comments on the current naming scheme? Note that the binary extension can be easily changed by modifying one line in the .spec file and building again. Handy for users who just want to forget about 1.5.2 and don't mind that some of the RedHat tools may break. Also, any other comments on the RPMs? Thanks, Sean -- Canadian phone sex: What kind of hockey jersey are you wearing? Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
Sean Reifschneider <jafo-python-dev@tummy.com> writes:
For test releases, I've been using the full release name as the extension, /usr/bin/python2.2c1 (or was it just python2.2?). This is so that multiple versions can be installed 1.5.2, 2.1, 2.2c1...
That doesn't really work, does it? 2.2c1 would overwrite /usr/lib/python2.2, which might be there from a prior Python 2.2 installation. If it is just python2.2, that scheme would work.
Also, any other comments on the RPMs?
Ideally, there should be an easy way to either install your RPMs alongside with the system RPMs, or to replace the system RPMs. In the latter case, 'rpm -U' could be used to upgrade from the system Python to your binaries. This might be tricky, as the names and structures of the Python RPMs vary widely. Regards, Martin
On Wed, Mar 27, 2002 at 10:33:47AM +0100, Martin v. Loewis wrote:
For test releases, I've been using the full release name as the extension, /usr/bin/python2.2c1 (or was it just python2.2?). This is so that multiple versions can be installed 1.5.2, 2.1, 2.2c1...
That doesn't really work, does it? 2.2c1 would overwrite /usr/lib/python2.2, which might be there from a prior Python 2.2 installation. If it is just python2.2, that scheme would work.
It doesn't work when going from 2.x* to 2.x*, but it does work in all other cases... That's more a python issue than an RPM issue though, as it's the same thing that would happen with a source install of Python (unless the libdir were re-located).
Ideally, there should be an easy way to either install your RPMs alongside with the system RPMs, or to replace the system RPMs. In the latter case, 'rpm -U' could be used to upgrade from the system Python to your binaries. This might be tricky, as the names and structures of the Python RPMs vary widely.
That is the way it's set up right now. The binary RPMs you download from python.org install and provide "python2", which can be installed along-side the stock RedHat python (which installs and provides "python"). However it's easy to change the RPM build so that you can take the source RPM and build without the binary extension (creating a 2.2 RPM which provides "python"). Sean -- Read error: 666 (Connection reset by Satan) Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
On Wed, 27 Mar 2002 18:27:36 -0700, Sean Reifschneider wrote:
It doesn't work when going from 2.x* to 2.x*, but it does work in all other cases... That's more a python issue than an RPM issue though, as it's the same thing that would happen with a source install of Python (unless the libdir were re-located).
We have good results with installing into fully versioned directories, and then symlinking a generic path to the latest installed version in the RPM %post script, i.e. /.../spam -> spam-1.2.3 /.../spam-1.2.3 This allows parallel installs of several versions, and easy switching back and forth between them. Works for our requirements, YMMV. Ciao, Jürgen
On Thu, Mar 28, 2002 at 02:38:14AM +0100, Juergen Hermann wrote:
We have good results with installing into fully versioned directories, and then symlinking a generic path to the latest installed version in the RPM %post script, i.e.
Well, the problem with that is that you're kind of circumventing the packaging system... The packaging system can't determine if that link has changed, or if other software conflicts with it. Not an earth-shattering situation, but something I try to avoid in the RPMs I distribute...
This allows parallel installs of several versions, and easy switching back and forth between them. Works for our requirements, YMMV.
I'd say that the packages themselves make it easy to switch back and forth between versions. "rpm -e package; rpm -i /tmp/package-previous.rpm"... Sean -- "If all you have is a hammer, every problem tends to look like a nail." Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
On Wed, 27 Mar 2002 21:59:00 -0700, Sean Reifschneider wrote:
I'd say that the packages themselves make it easy to switch back and forth between versions. "rpm -e package; rpm -i /tmp/package-previous.rpm"...
Not when you have dependencies, and when you want to run versions in parallel. Ciao, Jürgen
On Thu, Mar 28, 2002 at 07:19:36PM +0100, Juergen Hermann wrote:
I'd say that the packages themselves make it easy to switch back and forth between versions. "rpm -e package; rpm -i /tmp/package-previous.rpm"...
Not when you have dependencies, and when you want to run versions in parallel.
"--nodeps" if you have dependencies... As far as running two versions as the same time, I don't see how the sym-link helps... If both versions are looking for /usr/lib/python2.2, one of them is gong to be suprised at what it finds there. Sean -- Let us live!!! Let us love!!! Let us share the deepest secrets of our souls!!! You first. Sean Reifschneider, Inimitably Superfluous <jafo@tummy.com> tummy.com - Linux Consulting since 1995. Qmail, KRUD, Firewalls, Python
participants (4)
-
j.her＠t-online.de -
martin＠v.loewis.de -
Sean Reifschneider -
Sean Reifschneider