Re: RFS: harvestman web crawler - needs updation!
Piotr Ozarowski gmail.com> writes: > > > dh_fixperms will do the job > > > > Removed. > > Hmm... I pasted one line too much - config.xml file is installed with > dh_installexamples and thus permissions are not changed, please change > them manually as you did before (I hope you're not mad at me that I > didn't test it further; `find ...|chmod ...` changed permissions in upstream > sources as well, and thats why I didn't notice that before, sorry) I remember that I went through all this initially, and that is why I had that line. I'm was not too sure why you asked me to remove it, but didn't realise that it caused this because I forgot that it was needed! I have put it back now. > use: > find ./debian/harvestman/usr/ -name '*\.py' | xargs sed -i -e '1 s|^#\!.*python.*|#!/usr/bin/$(PYTHON)|' > > (you used "python2.4" again, with "$(PYTHON)" it will be easier when > current python will be greater than 2.4) Ah, missed that! It's OK now. > You're now making link to /usr/share/pycentral/..., please use: > dh_link -i /usr/lib/$(PYTHON)/site-packages/HarvestMan/harvestman.py /usr/bin/harvestman > instead (compiled files will be placed in /usr/lib/...) Done. > > Please get back to me for corrections. > > It's not very important, but if I were you, I would remove configure* > rules (they're not used) and collapse build-$(PYTHON), build-common and > build-common-stamp into build-stamp, same with install-$(PYTHON) / > install-prereq Done. > One more thing: please bump debhelper version in Build-Depends to > 5.0.37.3 (fixed python version in XS-Python-Version parsing issue) > Done. Now, I think there aren't too many things that need to be changed. But tell me if anything else is needed, and I shall do the needful. This discussion was fruitful, for two reasons. One is, I cleaned up rules. Two, the new policy takes time getting used to, but solves a lot of the problems with the old way of building Python packages, I feel. Thanks a lot. Kumar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: harvestman web crawler - needs updation!
Kumar Appaiah ee.iitm.ac.in> writes: > Thanks a lot. And again, get it at: http://kumar.travisbsd.org/debpackages/harvestman_1.4.6-3.dsc Thanks! Kumar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: RFS: harvestman web crawler - needs updation!
Kumar Appaiah ([EMAIL PROTECTED]): > And again, get it at: > http://kumar.travisbsd.org/debpackages/harvestman_1.4.6-3.dsc Looks very good to me. As I said before, I'm not a DD so I can't sponsor it. If you want, you can also add these 2 lines to long description: . Homepage: http://harvestman.freezope.org/ ^- don't miss this extra space (dev. ref. 6.2.4) PS Please remember to change XS-Python-Version from "2.4" to "current" and "python-all-dev" to "python-dev" in Build-Depends-Indep after python2.4 will become current (with next upstream version upload, package will work without any changes with python2.4 as current so no need to extra upload) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgps8OocEjE77.pgp Description: PGP signature
Re: dh_python and python policy analysis
Manoj Srivastava writes: > policy document. The current version, and future updates, are to be > found at http://www.golden-gryphon.com/software/manoj-policy/ unreachable, comments for the posted text follow > 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. There should be no reason to link the extension against the python library. Usually many extensions which are developed upstream on Windows do link by default to libpython. Other extensions linking against libpython are those with build infrastructure maybe predating distutils. python-semanage is an example (and should not link using -z defs). Another thing to mention here is a "Python package", a directory containing an __init__.py file plus modules and extensions. > 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. maybe shorten that to "all directories in sys.path"; not sure if an explicit list of directories is needed. > 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 These location are tool specific and should not be referenced explicitely in the packaging scripts (debian/rules) > 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: No, not the whole design goal. Although the document is titled "developer's view", the other goals should be mentioned as well. These are meant to work around processes in debian which are currently suboptimal, but unlikely to change. - The need to support more than one version of a python runtime or to support different implementations was seen. It takes a while until applications
Re: dh_python and python policy analysis
Le sam 12 août 2006 17:34, Matthias Klose a écrit : > dh_pysupport doesn't > use this information, but requires the developer to explicitely pass > the directory containing the extension module. that's not completely true, it only searches in /usr/lib/$pkg, /usr/share/$pkg, /usr/lib/games/$pkg and /usr/share/games/$pkg. If he finds a .so in there, he uses objdump to find out if the .so is python related or not, and acts accordingly. It just dont need current/current_ext at all, and uses different implementations choices. that's all. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpjOMeGLNEQ9.pgp Description: PGP signature
Re: dh_python and python policy analysis
Le sam 12 août 2006 17:34, Matthias Klose a écrit : > Manoj Srivastava writes: > > policy document. The current version, and future updates, are to > > be found at http://www.golden-gryphon.com/software/manoj-policy/ > > unreachable, comments for the posted text follow doh, that works for me ?! > >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. > > There should be no reason to link the extension against the python > library. Usually many extensions which are developed upstream on > Windows do link by default to libpython. Other extensions linking > against libpython are those with build infrastructure maybe predating > distutils. python-semanage is an example (and should not link using > -z defs). > Another thing to mention here is a "Python package", a directory > containing an __init__.py file plus modules and extensions. yes, that's indeed a thing to add. > >Public > > […] > > maybe shorten that to "all directories in sys.path"; not sure if an > explicit list of directories is needed. I've no real opinion on that. > > 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 > > These location are tool specific and should not be referenced > explicitely in the packaging scripts (debian/rules) agreed > No, not the whole design goal. Although the document is titled > "developer's view", the other goals should be mentioned as well. > These are meant to work around processes in debian which are > currently suboptimal, but unlikely to change. > > […] > >The alternative of dropping the python-foo package and just > keeping the pythonX.Y-foo packages was not followed anymore (ftp > master intervention and rewriting of control files). > > These are design decisions made for the distribution. There are > concerns about some upstream developers that the design of dropping > the pythonX.Y namespace for packages may not be rebust enough. > > Another consequence of the current design: the default python version > *has* to be installed, other supported versions can be installed > additionally, not as a replacement. agreed, this also has to be mentionned. > > 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. > > XS-Python-Version can have the values "current" and "current_ext" as > well (plus the list of ranges), which will expand to "current", if > the package does not have any extensions and can be used with another > python default version without a new upload. It's replaced by the > version number of the current default version in the Python:Versions > substitution variable. "current_ext" normally only needs to be used > for packages having a private extension module. dh_pysupport doesn't > use this information, but requires the developer to explicitely pass > the directory containing the extension module. IMHO current and current_ext are choices of implementations of pycentral, which your following explanations truly underline. [snip] > > 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. > > I think, that is too strict. The current behaviour is depending on > the dh_python implementation scanning all files for that interpreter > line. Consider a package with scripts in /usr/bin: foo, foo2.3, > foo2.4, calling python, python2.3 and python2.4, which would lead to > a dependency on all supported python versions. The scripts work for > the default python version, for the non-default python versions only > if the corresponding pythonX.Y package is installed. then the packager can choose to make those script use /usr/bin/python. I've seen very few of those packages, a
Re: RFS: harvestman web crawler - needs updation!
Piotr Ozarowski gmail.com> writes: > Looks very good to me. As I said before, I'm not a DD so I can't > sponsor it. Debian developers, please chip in! > If you want, you can also add these 2 lines to long description: > . > Homepage: http://harvestman.freezope.org/ > ^- don't miss this extra space (dev. ref. 6.2.4) Done that as well! With that space! :-) > PS Please remember to change XS-Python-Version from "2.4" to "current" > and "python-all-dev" to "python-dev" in Build-Depends-Indep after > python2.4 will become current (with next upstream version upload, > package will work without any changes with python2.4 as current so no > need to extra upload) I'll keep that in mind. Thanks. Kumar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
On Sat, 12 Aug 2006 17:34:06 +0200, Matthias Klose <[EMAIL PROTECTED]> said: > Manoj Srivastava writes: >> policy document. The current version, and future updates, are to be >> found at http://www.golden-gryphon.com/software/manoj-policy/ Unfortunately, you are commenting on an old version of the document, so some comments refer to issue that have already been addressed. >> 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. > There should be no reason to link the extension against the python > library. Usually many extensions which are developed upstream on > Windows do link by default to libpython. Other extensions linking > against libpython are those with build infrastructure maybe > predating distutils. python-semanage is an example (and should not > link using -z defs). I'll add these in general notes, or perhaps in the extension specific sections (since compilation rules do not belong in the classification section). > Another thing to mention here is a "Python package", a directory > containing an __init__.py file plus modules and extensions. This is mentioned in general notes; I did not think it was a useful fifth classification, since we do not actually treat it very differently. >> 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: >> > maybe shorten that to "all directories in sys.path"; not sure if an > explicit list of directories is needed. Not all paths in sys.path are oermitted in packages (like the path ending in .zip). >> 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 > These location are tool specific and should not be referenced > explicitely in the packaging scripts (debian/rules) You have just made all my selinux python packages violate this line :). I use update-python-modules in postinst and prerm, but I do not use any debhelper modules, and I should not be required to do so. I don't think that implicitly mandating the use of the helper scripts dh_(pysupport|pycentral|python) should belong in policy. >> 2. Goals of the new Python policy >> > No, not the whole design goal. Although the document is titled > "developer's view", the other goals should be mentioned as well. > These are meant to work around processes in debian which are > currently suboptimal, but unlikely to change. [SNIP lots of good stuff] I'll add these to the document. >> 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 > "2.3-" -> ">= 2.3", not "all". the range notation cannot express > things like "2.2, >= 2.4". The use case for the latter is the jython > package (now removed from testing) still at an implementation level > of the corresponding cpython version, with i.e. 2.3 not a supported > python version anymore. So in the following text "set of versions", > instead of "range of versions" should be used. OK, done. >> 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.) > Maybe mention the two cases, where the package size increases: > - extension modules > - pure modules where different versions of the upstream package are >shipped and are directly installed into /usr/lib/pythonX.Y/ OK. >> 3. Recipe for developers >> 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. >... and test rebuilds. OK. >> This can be a single version, or one or more of a list of >> non-overlappin
My take on the Python policy: draft
Hi, Here comes draft 1.0.4, with suggestions from Matthias Klose incorporated (well, most of them). The current and future updates, are to be found at http://www.golden-gryphon.com/software/manoj-policy/. The sources are at: http://www.golden-gryphon.com/software/manoj-policy/python-policy.xml, and are now licensed under th GPL (for some reason, docbook article mode suppresses LegalNotice). I am including a text version below. manoj Packaging with the new Python policy A package developers view Manoj Srivastava Developer The Debian Project Copyright (c) 2006 Manoj Srivastava Revision History Revision 1.0.4 12 Aug 2006 Revision 1.0.3 10 Aug 2006 Revision 1.0.2 8 Aug 2006 Revision 1.0.1 07 Aug 2006 Revision 1.0.0 31 Jul 2006 Specification of the new Python policy. This article grew as an attempt to correct a gap in the concrete specification of the new Python policy, and has grown to be close to a formal specification of the proposed new policy. -- Table of Contents 1. [1]Introduction 1.1. [2]Acknowledgements 2. [3]Goals of the new Python policy 3. [4]Nomenclature and definitions 3.1. [5]Python versions 3.1.1. [6]The Default Python version 3.2. [7]Categorization of Python software 4. [8]General Notes 4.1. [9]Naming python module packages 4.2. [10]Python versions supported by the source 4.3. [11]Byte compilation 4.4. [12]Linking extention modules 4.5. [13]Depends: 4.6. [14]Provides 4.7. [15]Build-Depends: 4.8. [16]Deprecating "current" in versions supported 5. [17]Recipe for developers 5.1. [18]Script 5.1.1. [19]Supported versions 5.2. [20]Private Pure Python Modules 5.2.1. [21]Byte compilation 5.2.2. [22]Supported versions 5.3. [23]Private Extension 5.3.1. [24]Supported versions 5.4. [25]Public pure Python Module 5.4.1. [26]Byte compiling 5.4.2. [27]Supported versions 5.4.3. [28]Depends: 5.5. [29]Public Extension 5.5.1. [30]Supported versions 5.5.2. [31]Provides 6. [32]Changing the default Python version 6.1. [33]Python rtupdate scripts 6.1.1. [34]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. So now this document is a draft formal specification of the proposed new Python packaging policy. While it draws upon earlier documents, notable [35]Debian Python Policy , and the [36]new policy Wiki, the [37]Debian Python FAQ, and the source code for dh_python, and debhelper scripts, it has essentially been written from scratch, with material reworded, reorganized, and rearranged, to the extent that it bears little resemblance to the original sources. Compiled Python modules are very dependent on the specific Python version they were compiled against, and may otherwise have restrictions on the versions of Python they are compatible with. Unless care is taken, introducing, or dropping, new versions of Python, or changing the default version, trigger long and often painful transitions where the archive is inconsistent, and the systems is ill-integrated for the duration. This new Python policy seeks to address these potential messy transitions, and minimize the pain. -- 1.1. Acknowledgements While this document draws upon the expertise of multiple people and various documents, it has benefited especially from the patience and gentle corrections of people on the Debian-devel mailing list, and specifically from Josselin Mouette, Loíc Minier, Pierre Habouzit, and Matthias Klose. -
