RPM File Naming Convention

RPM File Naming Convention

While RPM will run just as well if a package file has been renamed, when the packages are created during RPM's build process, they follow a specific naming convention. The convention is:

name-version-release.architecture.rpm


where:

*name is a name describing the packaged software.
*version is the version of the packaged software.
*release is the number of times this version of the software has been packaged.
*architecture is a shorthand name describing the type of computer hardware the packaged software is meant to run on. It may also be the string src, or nosrc. Both of these strings indicate the file is an RPM source package. The nosrc string means that the file contains only package building files, while the src string means the file contains the necessary package building files and the software's source code.

A few notes are in order. Normally, the package name is taken verbatim from the packaged software's name. Occasionally, this approach won't work — usually this occurs when the software is split into multiple "subpackages," each supporting a different set of functions. An example of this situation would be the way ncurses was packaged on Red Hat Linux Linux. The package incorporating ncurses basic functionality was called ncurses, while the package incorporating those parts of ncurses' program development functionality was named ncurses-devel.

The version number is normally taken verbatim from the package's version. The only restriction placed on the version is that it cannot contain a dash "-".

The release can be thought of as the package's version. Traditionally it is a number, starting at 1, that shows how many times the packaged software, at a given version, has been built. This is tradition and not a restriction, however. Like the version number, the only restriction is that dashes are not allowed.

The architecture specifier is a string that indicates what hardware the package has been built for. There are a number of architectures defined:

*i386 — The Intel x86 family of microprocessors, starting with the 80386.
*alpha — The Digital Alpha/AXP series of microprocessors.
*sparc — Sun Microsystem's SPARC series of chips.
*mips — MIPS Technologies' processors.
*ppc — The Power PC microprocessor family.
*m68k — Motorola's 68000 series of CISC microprocessors.
*SGI — Equivalent to "MIPS".

This list will almost certainly change. For the most up-to-date list, please refer to the file /usr/lib/rpmrc. It contains information used internally by RPM, including a list of architectures and equivalent code numbers.

Python egg is:

If you don’t know what a Python egg is, it’s simply a way of distributing Python packages, similar to RPM. There is also an easy method of installing them, using easy_install.

Where do I find Python Eggs?

You can find Python Eggs on quite a few places on the web, e.g. at a package author’s website. The biggest repository of eggs is the Cheeseshop (or PyPI) though), an index for Python packages. In order to be able to install eggs you simply need to install easy_install which is easily done by downloading ez_install.py (you can download it here) and calling it (you need to have rights to install components in your python installation of course).

Once you have done this you can simply install an egg by calling:

easy_install somepackage.egg

You can also give a URL to an egg and use

easy_install http://somehost.somedomain.com/somepackage.egg

If an egg is not found at that location or in the directory you give, easy_install will automatically query the Cheeseshop for the egg location. So if you want to install SimpleJSON you simply give

easy_install simplejson

and it will download and install the most recent version. If you are not running as root and you have Python installed as root you of course need to use something like “sudo easy_install” instead (e.g. on MacOSX).

A great additional feature is also that Eggs can define dependancies on other packages which easy_install will then try to automatically download and install aswell.

BTW, the easy_install program is part of the setuptool package by Philip Eby and is based on the distutils package which is part of the standard python distribution.

refer more : click here

http://onlamp.com/pub/a/python/2005/01/27/ipython.html

============================================
try this to install ipython for python2.4
=============================================

[root@root]# wget http://pypi.python.org/packages/2.4/s/setuptools/setuptools-0.6c9-py2.4.egg

[root@root]# sh setuptools-0.6c9-py2.4.egg

[root@root]# easy_install-2.4 http://ipython.scipy.org/dist/ipython-0.8.4-py2.4.egg

[root@webdev tgzfiles]#

cherrypy

CherryPy is a pythonic, object-oriented HTTP framework.

CherryPy allows developers to build web applications in much the same way they would build any other object-oriented Python program. This results in smaller source code developed in less time.

CherryPy is now more than six years old and it is has proven very fast and stable. It is being used in production by many sites, from the simplest ones to the most demanding ones.

Oh, and most importantly: CherryPy is fun to work with :-) Here's how easy it is to write "Hello World" in CherryPy 3:

import cherrypy

class HelloWorld(object):
def index(self):
return "Hello World!"
index.exposed = True

cherrypy.quickstart(HelloWorld())



Find More on http://www.cherrypy.org/