Hi, Another day, another draft.
Here is the latest update for my take on the new Python policy document. The current version, and future updates, are to be found at http://www.golden-gryphon.com/software/manoj-policy/ I am including a text version below. manoj
Packaging with the new Python policy A package developers view Manoj Srivastava Copyright (c) 2006 Manoj Srivastava Revision History Revision 1.0.4 25 Jul 2006 Obstacles to conformance with the new python policy. While the new Python policy, specifically the [1]"Packaged Modules" chapter, contains the elements that must be present in the debian/control filename, it is not very explicit about how the values are to be substituted. The Debian Wiki falls back on calling dh_python, which is not helpful in understanding the actual logic to be followed. This article is an attempt to correct this gap in documentation. -------------------------------------------------------------------------- Table of Contents 1. [2]Introduction 1.1. [3]Categorization of Python software 2. [4]Goals of the new Python policy 3. [5]Recipe for developers 3.1. [6]General Notes 3.1.1. [7]Python versions supported by the source 3.1.2. [8]Depends: 3.1.3. [9]Provides 3.1.4. [10]Build-Depends: 3.2. [11]Deprecating "current" in versions supported 3.3. [12]Script 3.3.1. [13]Supported versions 3.4. [14]Private Pure Python Modules 3.4.1. [15]Byte compilation 3.4.2. [16]Supported versions 3.5. [17]Private Extension 3.5.1. [18]Supported versions 3.6. [19]Public pure Python Module 3.6.1. [20]Byte compiling 3.6.2. [21]Supported versions 3.6.3. [22]Provides: 3.7. [23]Public Extension 3.7.1. [24]Supported versions 3.7.2. [25]Provides 4. [26]Changing the default Python version 4.1. [27]Python rtupdate scripts 4.1.1. [28]rtupdate script invocation 1. Introduction While trying to update SELinux packages, I ran across problems in trying to determine if my packages were complying with the new python policy: any practical tips for packaging generally devolved to the statement "Oh, just run dh_python". This is my attempt to offer more concrete tips for packaging. While this document started by reverse engineering dh_python, it has, thanks to help from various people more knowledgeable about Python than I, moved beyond that, and is closer to being a specification unfettered by the idiosyncrasies of current tools and implementations. -------------------------------------------------------------------------- 1.1. Categorization of Python software Program/script This consists of software directly called by an end user of external program, and is independently interpreted by the Python interpreter. Usually starts with the magic bytes #!, with the interpreter being /usr/bin/python* or /usr/bin/env python*. Modules This is code included in python "programs/scripts", and not invoked directly (serving as library modules in compiled languages). Modules can be categorized under two orthogonal criteria: firstly, based on the whether or not they are implemented purely in python, like so: Pure Python Module These are python source code, to be interpreted by the Python interpreter just like program/script code is, and may work across many versions of Python. Extension Module Extensions are C code compiled and linked against a specific version of the libpython library, and so can only be used by one version of Python. Another way of categorizing modules is based on whether or not they are available for use by third party scripts/modules. Public Public modules are available for use in other Python scripts or modules using the import directive. They are installed in one of the directories: /usr/lib/pythonX.Y This directory is reserved for official python modules. No other package apart from upstream official Python modules should install modules in this directory. /usr/lib/pythonX.Y/site-packages This is where most add-on modules live. Often, packages do not directly install modules here, but instead use utility packages like python-central and python-support to byte compile and install modules as needed. /var/lib/python-support/pythonX.Y Packages using python-support actually have their packages linked in from this directory, but no package should directly install modules there directly. See the documentation for python-support for details. Packages may install public Python modules in directories specific to Python packaging utilities -- which specify the directories under which such modules should be droppped, and the the structure of these directories is defined by the utilities themselves. Please note that these directories are not in the path for Python, and are not available for modules to be imported from. At the time of writing, such uility specific directories include: /usr/share/pycentral /usr/share/python-support . Private Private modules are modules that are used internally by a program, and are generally only accessible to that specific program or suite of programs included in the same package. They are not intended to be shared with third party programs. They are installed in special directories, for example: /usr/lib/<package> /usr/share/<package> /usr/lib/games/<package> /usr/share/games/<package> -------------------------------------------------------------------------- 2. Goals of the new Python policy The new policy is designed to reduce the load on people packaging python modules when one of the following events occur, and, by the dint of doing so, ease the transition that occur as new Python versions are introduced, old ones removed, and as the default version of Python changes, with minimal impact on the target system. In case of the following events: New python version introduced * Most pure Python modules with no restrictions on the version of Python supported, and those pure Python modules that only have a lower bound on the versions of python supported (for example, "2.3-", or "all"), would require no upload; they are merely recompiled using the rtupdate hooks, or utilities like python-central and python-support that hook themselves into rtupdate. * A number of public extension modules that do not have restrictions on the version of Python supported can just be recompiled. These include packages like: * Packages using $(shell pyversions -s) to determine which python versions to build for at build time, and which build depend upon python-all-dev would work seamlessly. * Some packages using CDBS will also work out of the box. * Packages using the distutils build system should also work. * Private modules are only built for one Python version, usually the default (pyversion -d). Private modules that do not have restrictions on the version of Python required, or which intelligently use $(shell pyversions -s) and their internal restrictions to discover which version of Python to build for would also merely need to be recompiled. The only packages that will need manual upgrades, are packages that needed a range of python versions that did not contained the (at the upload time) current python version, and a couple of other cases, which should reduce the packages that need a non-automatized action from the maintainer (like a new source upload). This reduction of manual intervention should reduce the effort and time taken for changing the Python version or adding or dropping versions of Python much more painless than the old policy. Changing the default Python version The new policy aims to reduce the pressure on packagers when th default Python version (what /usr/bin/python points to) changes. In that case, it tries to: * Any packages that do not need to change need not be rebuilt or uploaded. Pure Python modules, either public or private, should be byte compiled automatically on th target machine using the rtupdate mechanisms. * Packages that have already an extension installed for the new version of Python do not need to change either, since they would continue to keep working. Dropping old Python versions The new policy also aims to reduce the pressure when an old version of Python is dropped, since only packages directly dependent on that version will need a manual upgrade (this includes, for example, any package with scripts that use /usr/bin/pythonX.Y). The new policy also reduces the numbers of packages in the archive, by supporting multiple versions of Python in the same binary package (at the cost of increased size of that one package, but it should still result in space saving.) This presupposes that the package build mechanism utilizes the utility pyversions to get information about the supported Python versions, the currently installed Python executable versions, and the default Python runtime, instead of hard coding values in the debian/rules script. This script can also be used to parse the value of the XS-Python-Version field in the debian/control or debian/pyversions. -------------------------------------------------------------------------- 3. Recipe for developers 3.1. General Notes This is essentially a restatement of policy and dh_python internals to allow one to look at the type of python components being shipped in the package, and get an idea of what the expectation of policy is, based on both the policy and dh_python. My notes on the internal implementation of dh_python are also [29]provided for reference. There is certain amount of duplication in the sections below, but I have elected to leave it in place, so each section on each type of module is self contained. One of the major features of Python packaging on Debian systems is that pure Python modules are byte compiled for all officially supported versions of Python that are available, and are actually supported by the module itself. There are several utilities available to aid in this task. Two of the most popular (and mutually exclusive -- select one or the other for use in your packages) (python-central and python-support, for example). However, these utilities need information about modules in the package (for example, whether a pure Python module supports all versions of Python or not). -------------------------------------------------------------------------- 3.1.1. Python versions supported by the source The XS-Python-Version field in debian/control specifies the versions of Python supported by the package [30][1]. While this is a requirement only if using the utility package python-central (python-support, for example, prefers debian/pyversions), setting this is "appreciated" in any case, according to the [31]new policy wiki[32][2]. This is used to track packages during Python transitions. This can be a single version, or one or more of a list of non-overlapping ranges. The lowest range may optionally omit a low end, and the highest range may optionally omit an upper end. In other words, the overall range may be open ended. The ranges are often matched to the set of all known Python version that have existed, and the supported set is the intersection of the known versions of python and the range specification. 1. If the current version of Python is supported by the package, then: * For packages with private modules or private extensions compiled for the current python version and for applications using /usr/bin/python, this should be set to the string "all" (or "-", in the case of debian/pyversions). [33][3] If the module doesn't work with all Python version, the range of versions supported should be used [34][4] * For packages with public modules, this should be set to the string "all" (or "-", in the case of debian/pyversions), unless not all versions of Python are supported (in which case the setting should specify the versions or range of versions actually supported, like ">= 2.4" or ">= 2.2, << 2.y". 2. If the current version is not supported, or if the application uses /usr/bin/pythonX.Y explicitly, then this should be set to the (list of) version(s) supported. -------------------------------------------------------------------------- 3.1.2. Depends: The rules for calculating the dependencies a package has are simple. 1. If a script invokes /usr/bin/pythonX.Y, than the package must depend on pythonX.Y. This is because no amount of automatic byte compiling would ever get rid of the requirement that /usr/bin/pythonX.Y has to be present for the script to function. 2. For package that contains extensions, the range of Python versions required has to be restricted to Python versions for which the extensions have been built and shipped in the package. For packages with private extension modules, this means that the range of python versions it depends on has to be set to whatever version of Python was used during the build process (since private extension module packages can only be compiled for one version of Python at any time). 3. a. i. If any version of python can be supported, there are two [35][5] sub cases: A. For pure Python modules, the package just depends on python. This includes pure Python private modules (as long as they do not depend on any private extensions -- in which case the extensions shall restrict the dependency). B. Private extension modules can only be compiled for one version of Python at a time, so even if they have no restrictions on the versions of python supported, they must depend on just the current version (which is the version they are likely to be compiled for). To do this, one determines the stop version: the stop version is next minor version after the current version (found by incrementing the minor version), whether or not it exists, and is form of Major.Minor. In this case, the package must depend on: python (>= $current_version), python (<< $stop_version) b. If there is a range of values of versions of Python supported, there are two sub cases: i. The current version is supported. In this case, select the larger interval in the range of Python versions supported that contains the current version, and determine the lower and upper bounds. If the lower bound to the range exists, then add a dependency on python (>= $min_version) If the upper bound to the range exists, then the stop version is the next minor version after the upper bound (found by incrementing the minor version), whether or not it exists, and is form of Major.Minor. If the upper bound to the range exists, then depend on python (<< $stop_version) ii. The package does not support the current version of Python, again, there are again two sub cases: A. The range of Python versions supported is higher than the current version. In this case, the package should depend upon: python (>= $min_version) | python$min_version) If the upper bound to the range exists, then the stop version is the next minor version after the upper bound (found by incrementing the minor version), whether or not it exists, and is form of Major.Minor. If the upper bound to the range exists, then depend on python (<< $stop_version) B. The range of Python versions supported is lower than the current version. This implies that the package is obsolete, and should either be updated to support the current Python version, or be dropped from the archive. Packaged modules that require other modules to work, must depend on the corresponding python-foo packages. They must not depend on any pythonX.Y-foo package directly. Packaged modules available for only one particular version of Python that need other modules (say, "bar"), must depend on the corresponding pythonX.Y-bar packages, and must not depend on any python-bar. For consistency, if the package ("foo") provides several pythonX.Y-foo packages, and it needs the module "bar", it must also depend on pythonX.Y-bar corresponding to each version "X.Y" for the virtual packages pythonX.Y-foo that it provides. -------------------------------------------------------------------------- 3.1.3. Provides Packages with public modules and extensions should be named, or should provide, python-foo. Pure Python public modules that support all Python versions need not have a Provides field. For package that contains public extensions, the range of versions supported has to be restricted to Python versions for which the extensions have been built and shipped in the package. Public pure Python modules that have a subset of all python versions supported, or for public extensions, the Provides field indicates which versions of Python are supported (for which one may import the module). For every version of python supported the package should provide pythonX.Y-foo packages. This assumes that the package correctly depends on all the appropriate versions of any version specific module that it itself requires. -------------------------------------------------------------------------- 3.1.4. Build-Depends: If the package provides public extension modules, then build depending on "python-all-dev (>= 2.3.5-11)" shall ensure that all the >pythonX.Y-dev packages are available during building. On the other hand, if the package provides private modules, then build depending on "python-dev", or one specific "pythonX.Y-dev" (if there are restrictions on the version of Python supported) is sufficient, since only one version of Python is ever supported in any package. If you are using helper packages (CDBS, yada, debhelper, etc) you should build depend on the appropriate version. This also applies if your build process uses either python-central or python-support. -------------------------------------------------------------------------- 3.2. Deprecating "current" in versions supported Currently, the string "current" in the field XS-Python-Version is used by python-central to indicate that the package contains private modules, and explicitly state that the package is only built for the current Python version, and not for any other version supported in Debian. This is flawed, for the following reasons: * The value corresponds to the version of Python the package is currently built for; but in all other cases the semantics of the XS-Python-Version field is to indicate which versions of Python are supported by the package, and indicates compatibility, not the version it is currently built against. So this special case breaks the semantics of the field. * By hijacking the XS-Python-Version field to indicate the version of Python it is currently compiled against, it hinder s the propagation of compatibility information, so the ability of the maintainer to indicate the range of Python versions this package is compatible with. * The information conveyed by this field is redundant; it should be clear that the package contains private modules, based on the directories the modules are shipped in, and also the fact that it ought to build depend on python-dev and not on python-all-dev. * The semantics of "current" are not fixed, since they depend on the contents of the package python-defaults, and are ill suited for the debian/control file. -------------------------------------------------------------------------- 3.3. Script These are executable scripts which start with the magic string #!. -------------------------------------------------------------------------- 3.3.1. Supported versions If a script invokes /usr/bin/pythonX.Y, then the version supported by the source package (XS-Python-Version or debian/pyversions) should be restricted to X.Y, assuming that the field is being provided. Or else, it should be set to the list of python versions that the script can support, or "all". [36][6] If there are separate scripts that invoke different versions of Python, then all these versions must be in the Depends field -- if you still want to continue packaging instead of just shooting the upstream. No script must use /usr/bin/python if it needs a Python version strictly greater or strictly lower than the current version. -------------------------------------------------------------------------- 3.4. Private Pure Python Modules These are python source code files that live in a private directory. If a package contains a private pure Python module, only one Python version may be supported, even if the private module can be recompiled for any new version of Python. -------------------------------------------------------------------------- 3.4.1. Byte compilation Any directory in which private pure Python modules are placed should be remembered, and the modules byte-compiled on installation. This is done automatically if one uses python-central, python-support uses the information in the file /usr/share/python-support/$package.dirs for a list of directories to scan. -------------------------------------------------------------------------- 3.4.2. Supported versions The version supported by the source package (XS-Python-Version or debian/pyversions) is either the specific version of Python supported, or "all" [37][7] , if there are no specific restrictions based on Python version. This should be set to "all" [38][8] if there are no specific restrictions based on Python version. Note that presence of private extension modules in the same package would mean that there are restrictions on the XB-Python-Version field. If only a subset of Python versions are supported by the package, then the list of versions supported should be used [39][9] -------------------------------------------------------------------------- 3.5. Private Extension These are compiled files linked to python libraries, and kept in a private directory. Since these files are compiled with one specific version of python, and do not live in versioned directories, only one version of python is supported at any given time. -------------------------------------------------------------------------- 3.5.1. Supported versions The version supported by the source package (XS-Python-Version or debian/pyversions) is either the specific version of Python supported, or "all" [40][10], if there are no specific restrictions based on Python version. If a single version of Python is supported, then the versions supported by the binary package (XB-Python-Version field or the file .versions) is set to that version (copied from XS-Python-Version). If the current version is not supported, this field it set to the minimum version actually supported by the module. If the current version is supported (or there are no restrictions on the version of python supported), then this field is set to the current version. -------------------------------------------------------------------------- 3.6. Public pure Python Module Public modules should be packaged with a name of python-foo, where foo is the name of the module. Such a package should support the current Debian Python version, and more if possible. There are two kinds of public pure Python modules, the most common being the variety that live in unversioned public module directories, and, in rare cases, pure python modules that live in versioned public module directories. The latter is usually the case when the pure Python module imports an public extension module from the same directory, and thus the public extension and pure python modules must be in the same directory. Otherwise, pure python modules should live in an unversioned public module directory. Depending on the packaging utility used, the modules live in either /usr/share/python-central or in /usr/share/python-support/$package. Official pure Python modules generally live in a different set of directories than unofficial ones, but are otherwise treated exactly like other public pure Python Module which live in unversioned directories as detailed below. -------------------------------------------------------------------------- 3.6.1. Byte compiling In the common case of pure Python modules in unversioned public module directories, tools exist to help byte compile the pure Python modules for all versions of Python installed on the target system. In case of pure Python modules in versioned public module directories, byte compilation is up to the package scripts. -------------------------------------------------------------------------- 3.6.2. Supported versions For the source package, this should be the version of Python supported, or "all", if there are no specific restrictions based on Python version. In case of pure Python modules in versioned public module directories, the set of versions supported usually corresponds to the list of versioned directories in which pure Python modules live. -------------------------------------------------------------------------- 3.6.3. Provides: Dependencies for the package also differ slightly based on whether the pure Python module is version dependent or not. 1. In the common case of pure Python modules in unversioned public module directories, a. If there is a minimum supported version, i. If the minimum version supported is less than or equal to the current version, then depend on python (>= $min_version) ii. Or else, if the minimum version supported is greater than the current version, then depend on python (>= $min_version) | python$min_version If a upper bound of the supported versions exists, then the stop version is the next minor version after the maximum supported version (found by incrementing the minor version), whether or not it exists, and is form of Major.Minor. If there is an upper bound on the supported versions, and the upper bround is greater than or equal to the current version, then depend on python (<< $stop_version) b. If the current version is higher than any supported version, then this package is obsolete. However, the following dependencies are still valid, if the corresponding lower and upper bounds of supported versions exist. python (>= $min_version) | python$min_version, python (<< $stop_version) 2. In case of pure Python modules in versioned public module directories, the set of versions corresponding to the list of versioned public module directories in which pure Python modules live is used in lieu of the value of XS-Python-Version. a. If the lowest version in the set is less than or equal to the current version, then depend on python (>= $min_version) b. Or else depend on python (>= $min_version) | python$min_version, c. If the highest version in the set is greater than or equal to the current version, then depend on python (<< $stop_version) where the stop version is the next minor version greater than the highest supported version. d. For every version in the set, also depend on python$version -------------------------------------------------------------------------- 3.7. Public Extension Public extensions should be packaged with a name of python-foo, where foo is the name of the module. Such a package should support the current Debian Python version, and more if possible. Depending on the packaging utility used, the modules live in either /usr/lib/pythonX.Y/site-packages or in /usr/lib/python-support/$package/pythonX.Y, with proper symbolic links in place. -------------------------------------------------------------------------- 3.7.1. Supported versions The versions supported by the source and binary packages should be set to the list of versions for which the compiled extension modules are provided. -------------------------------------------------------------------------- 3.7.2. Provides For every version of Python for which compiled extension modules are provided, provide a package named pythonX.Y-foo (assuming that the package name is python-foo). -------------------------------------------------------------------------- 4. Changing the default Python version Some packages may need more changes during an update of the default python version (i.e. setting an alternative, restarting a daemon). These packages can either provide their own upgrade scripts (run during the update of the default python version), or continue to use the old dependency on exactly the current python version to ensure that the package is updated together with the default python version and use the normal installation/removal scripts. The utility packages python-central and python-support provide upgrade scripts in order to facilitate their byte compilation work. [41][11] -------------------------------------------------------------------------- 4.1. Python rtupdate scripts When the default python version is changed, the maintainer scripts of the python package arrange for the execution of package provided scripts. These scripts are placed in /usr/share/python/runtime.d/, must have an .rtupdate extension and must be executable. These scripts must be idempotent; since any script may be called multiple times during a Python version change with the same arguments. These scripts must be rigorously tested, since any failure in the scripts would make the new Python package changing the default version to fail to install. Each script is called with one of pre-rtupdate, rtupdate or post-rtupdate as the first parameter. If nothing needs to be done the invocation should be ignored by the script. -------------------------------------------------------------------------- 4.1.1. rtupdate script invocation 1. in the pre-installation phase of the python package, the package supplied scripts are called with the parameter: pre-rtupdate <old runtime> <new runtime> A failure in any script results in the failure of the pre-installation script of the python package. [42]Note Whether or not all scripts are run, or the process aborts at the first failure, is still under flux Since such a failure of a script would leave all packages whose pre-rtupdate has been run in a dangling state, a bug in a pre-rtupdate will always be a critical bug. Be very very careful when working on a pre-rtupdate script. 2. During the post installation phase of the python package, the package supplied scripts are called with the parameter: rtupdate <old runtime> <new runtime> This is the hook used by python-central and python-support to byte compile pure Python modules; and packages handling their own byte compilation should use this hook as well. A failure in any script results in the failure of the post-installation script of the python package. Such a failure only affects the package which owns the script, and does not impact the other related packages, so a problem in the pos-rtupdate script is less critical, and would only have the severity grave or serious. 3. During the post installation phase of the python package, the package supplied scripts are called with the parameter: post-rtupdate <old runtime> <new runtime> A failure in any script results in the failure of the post-installation script of the python package. Notes [43][1] python-central also uses XB-Python-Version field in the control file, which is substituted in the binary package using the values from the XS-Python-Version field, filtered according to various rules. [44][2] For compatibility, each of the tools (python-central and python-support) are able to use each others data. [45][3] Note that pycentral uses the special string "current" here. [46][4] For pycentral, one may specify something like "current, >= 2.4" or even "current, >= 2.2, << 2.5". [47][5] Public extensions are restricted to the list of Python versions for which the extensions have been compiled, and thus are covered in the section below. [48][6] If the package uses python-central, and if there is no other value for the versions (set by any modules packaged), then the versions spported by the binary package (XB-Python-Version) is the same as above (XS-Python-Version, if XS-Python-Version is not empty, or "all", if it is empty). [49][7] If using python-central, use the special string "current" instead of "all". [50][8] If using python-central, use the special string "current" instead of "all". Note that if the package contains private extention modules, then the rules for setting XB-Python-Version for the private extention modules take precedence. [51][9] python-central differs here. If the current version is supported, then XB-Python-Version should be set to "current". If the current version is not supported, and if the minimum version supported is strictly higher than the current version, the XB-Python-Version field should be set to the minimum version supported. Failing that, if the current version is not supported, and the max version is lower than the current version, then this package should be deprecated, and is obsolete. [52][10] If using python-central, use the special string "current" instead of "all". [53][11] This section is based on [54]basic rtupdate documentation References Visible links 1. http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html 2. file:///tmp/html-g14429#AEN38 3. file:///tmp/html-g14429#AEN44 4. file:///tmp/html-g14429#AEN121 5. file:///tmp/html-g14429#AEN183 6. file:///tmp/html-g14429#AEN185 7. file:///tmp/html-g14429#AEN195 8. file:///tmp/html-g14429#AEN244 9. file:///tmp/html-g14429#AEN315 10. file:///tmp/html-g14429#AEN325 11. file:///tmp/html-g14429#AEN339 12. file:///tmp/html-g14429#AEN362 13. file:///tmp/html-g14429#AEN366 14. file:///tmp/html-g14429#AEN383 15. file:///tmp/html-g14429#AEN386 16. file:///tmp/html-g14429#AEN392 17. file:///tmp/html-g14429#AEN421 18. file:///tmp/html-g14429#AEN424 19. file:///tmp/html-g14429#AEN439 20. file:///tmp/html-g14429#AEN447 21. file:///tmp/html-g14429#AEN450 22. file:///tmp/html-g14429#AEN454 23. file:///tmp/html-g14429#AEN504 24. file:///tmp/html-g14429#AEN510 25. file:///tmp/html-g14429#AEN513 26. file:///tmp/html-g14429#AEN518 27. file:///tmp/html-g14429#AEN526 28. file:///tmp/html-g14429#AEN537 29. file:///tmp/python_policy.txt 30. file:///tmp/html-g14429#FTN.AEN200 31. http://wiki.debian.org/DebianPython/NewPolicy 32. file:///tmp/html-g14429#FTN.AEN210 33. file:///tmp/html-g14429#FTN.AEN225 34. file:///tmp/html-g14429#FTN.AEN229 35. file:///tmp/html-g14429#FTN.AEN262 36. file:///tmp/html-g14429#FTN.AEN373 37. file:///tmp/html-g14429#FTN.AEN398 38. file:///tmp/html-g14429#FTN.AEN405 39. file:///tmp/html-g14429#FTN.AEN413 40. file:///tmp/html-g14429#FTN.AEN430 41. file:///tmp/html-g14429#FTN.AEN523 43. file:///tmp/html-g14429#AEN200 44. file:///tmp/html-g14429#AEN210 45. file:///tmp/html-g14429#AEN225 46. file:///tmp/html-g14429#AEN229 47. file:///tmp/html-g14429#AEN262 48. file:///tmp/html-g14429#AEN373 49. file:///tmp/html-g14429#AEN398 50. file:///tmp/html-g14429#AEN405 51. file:///tmp/html-g14429#AEN413 52. file:///tmp/html-g14429#AEN430 53. file:///tmp/html-g14429#AEN523 54. http://people.debian.org/~doko/tmp/python-rtupdate.txt
-- On the other hand, life can be an endless parade of TRANSSEXUAL QUILTING BEES aboard a cruise ship to DISNEYWORLD if only we let it!! Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/> 1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C