dh_python and python policy analysis
Hi, I have finished my initial analysis of Python policy and dh_python, and created a rough specification of what the python policy is supposed to be (based on current dh_python behaviour). The current analysis, and future updates, are to be found at http://www.golden-gryphon.com/software/manoj-policy/ The document is a draft, since I have not been involved in Python development, it may have flaws, and I am hoping that people more conversant with Python development would point them out to me. The document could also stand some polishing; and since it was written piecemeal, continuity leaves much to be desired as yet. 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 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]Requirements for packages (new policy) 2.1. [5]XS-Python-Version: 2.2. [6]XB-Python-Version: 2.3. [7]Depends: 2.4. [8]Provides 3. [9]Recipe for developers 3.1. [10]Based on type of python modules being packaged 3.1.1. [11]Script 3.1.2. [12]Private Pure Python Modules 3.1.3. [13]Private Extension 3.1.4. [14]Public pure Python Module 3.1.5. [15]Public Extension 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, by reverse engineering dh_python for the specifications and tips. -- 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/site-packages /usr/lib/pythonX.Y /var/lib/python-support/pythonX.Y /usr/share/pycentral /usr/share/python-support Private Private modules are generally only accessible to a specific program or suite of programs included in the same package. They are installed in special directories, for example: /usr/lib/ /usr/share/ /usr/lib/games/ /usr/share/games/ -- 2. Requirements for packages (new policy) The new python policy places certain requirements for packages that contain Python bits. -- 2.1. XS-Python-Version: The XS-Python-Version field in debian
Re: dh_python and python policy analysis
Manoj Srivastava wrote: > Hi, > > I have finished my initial analysis of Python policy and > dh_python, and created a rough specification of what the python > policy is supposed to be (based on current dh_python behaviour). The > current analysis, and future updates, are to be found at > http://www.golden-gryphon.com/software/manoj-policy/ > > The document is a draft, since I have not been involved in > Python development, it may have flaws, and I am hoping that people > more conversant with Python development would point them out to me. > > The document could also stand some polishing; and since it was > written piecemeal, continuity leaves much to be desired as yet. > > 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 25 Jul 2006 > Not sure if I missed it, but you seem to claim a copyright but not give an explicit license. I imagine you meant to put it under GPL or a free version of the GFDL. Could you please clarify and also add it to the document? Regards, -Roberto -- Roberto C. Sanchez http://familiasanchez.net/~roberto signature.asc Description: OpenPGP digital signature
nominee blabbermouth
This is a multi-part message in MIME format. It seemed now that Jingle andMcGinty had been always part of her life -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.4
Norbert Tretkowski ([EMAIL PROTECTED]): > Speaking of libapache2-mod-python... can someone please take care of > the transition of libapache2-mod-python to the new python policy? I'll try to convert it -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpFgI3DIXWKC.pgp Description: PGP signature
Re: python2.4
* Andreas Barth wrote: > There are 18 packages which are in etch currently: Speaking of libapache2-mod-python... can someone please take care of the transition of libapache2-mod-python to the new python policy? Thanks, Norbert -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.4
* Matthias Klose ([EMAIL PROTECTED]) [060731 13:45]: > More than 90% of the bug reports filed by Pierre Habouzit for the > Python transition are currently solved. I'm not sure, if all of the > remaining ones should be addressed, or if the packages should just be > dropped. A lot of these are for software, where newer versions are in > the archive as well (gnome1, wxwindows2.4, ...). But again, you can > help here by NMUing packages which you would like to see in etch. > See http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED] There are 18 packages which are in etch currently: ecasound2.2 python-pymetar python-visual sip-qt3 vtk wxwindows2.4 gdal gnuradio-core libhid libmetakit2.4.9.3 libphidgets moin opencv pygtkmvc python-gdchart python-gnome libapache2-mod-python libapache-mod-python I bumped the non-etch packages now to serious. That will prevent testing transitions of new such packages. If you think that one of the packages above should be removed, please increase the severity to serious, and ping -release. Cheers, Andi -- http://home.arcor.de/andreas-barth/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: python2.4
Ganesan Rajagopal writes: > > Hi, > > Somebody had to ask again, so this time I'll do it. What's holding up > python2.4 as the default python even in unstable? upgrade testing; If you do want to help on it, please install the packages from experimental and check, if/what is going wrong. I would like to see some results from test upgrades. With yesterday's python2.x uploads these upgrades should succeed, but getting bug reports like #380597 doesn't look encouraging. So if you do want help, do a test upgrade. More than 90% of the bug reports filed by Pierre Habouzit for the Python transition are currently solved. I'm not sure, if all of the remaining ones should be addressed, or if the packages should just be dropped. A lot of these are for software, where newer versions are in the archive as well (gnome1, wxwindows2.4, ...). But again, you can help here by NMUing packages which you would like to see in etch. See http://bugs.debian.org/cgi-bin/[EMAIL PROTECTED] With most of the work done (regarding the pythonX.Y-foo packages), we have to change the default version to go on and convert the remaining ones. But again, it would be nice to see some reports about sucessful upgrades. Can you send one? Pierre agreed to prepare another mass bug filing for the remaining packages which need changes; Hope we can get this done by tonight. An unrelated thing is to make the interpreter link with the shared libpython (it will cost some performance, but some applications need it). The packages are prepared for that; if you can test it, please do. Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: More dh_python questions
Hi, (Could you please stop cross-posting to debian-devel? The discussion belongs to debian-python@ and the list is low traffic.) On Sun, Jul 30, 2006, Manoj Srivastava wrote: > I have only one version in XS-Python-Version (say, 2.4) I think the patch in #378604 enhance this situation with "XS-Python-Version: 2.4", but I had trouble too with "XS-Python-Version: 2.3", see thread on debian-python@, "Generation of "python" dependencies for public extensions versus python2.3". Also, the behavior seems completely clean for "XS-Python-Version: current", have a look at "flumotion" which has private modules which are compiled in place (in /usr/lib/flumotion) for the current version of python on install, and are recompiled on upgrades. Bye, -- Loïc Minier <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
python2.4
Hi, Somebody had to ask again, so this time I'll do it. What's holding up python2.4 as the default python even in unstable? Ganesan -- Ganesan Rajagopal -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
