Re: dpkg-repack warnings: what effect?
(Matthias drew my attention to this thread. Sorry I'm a bit late ...) Joey Hess <[EMAIL PROTECTED]> wrote: > Matthias Klose wrote: > > I haven't yet seen any reasoning why people are seeing that > > information as "cluttering the database" or just as "ugly". > > Causing unrelated programs like dpkg-repack to spew warning messages is, > by definition, ugly. > > Using X- fields, which are intended for nonstandard extensions, in the > core of Debian is also ugly. The reason the X*- fields have to be named like that in the package control file is that dpkg-source et al don't know which output control files to copy them into. I don't think there's anything inherently wrong with using X*- fields in a Debian-mandated way. The alternative would be to make the whole new mechanism depend on updated dpkg-source which seems pointless given that dpkg-source has an extension mechanism here for precisely this purpose. It would be nice if dpkg-source (and dpkg-deb) could be taught not to warn about this field. But the warning is harmless too: it's there to point out if you accidentally misspelling a field name. So ignoring the warning is fine. > Modify dpkg to properly add new fields if they're going to have common > usage in Debian. Using X- fields is fine for prototyping but not for > final implementations. I disagree. One of the things the IETF discovered was that renaming fields (or things in other namespaces) causes a lot of trouble and is to be avoided. So in general new IETF standards don't expect you to use x-* for new standards-track activities. Existing X-* fields have in some cases been grandfathered. We have to use X- for these fields for the reasons I've explained above. So I think we should be prepared to officially bless these particular names. Ian. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
RFS: harvestman web crawler - needs updation!
Dear Debian developers, My package, harvestman, has been marked with a severe bug related to the new Python policy. I have made the necessary updation. Please check it out at: http://kumar.travisbsd.org/debpackages (1.4.6-3 is what you should get...) In case there are problems, please let me know, so that I can correct them as necessary. Thanks. Kumar -- Kumar Appaiah, 462, Jamuna Hostel, Indian Institute of Technology Madras, Chennai - 600 036 signature.asc Description: Digital signature
Re: RFS: harvestman web crawler - needs updation!
Kumar Appaiah ([EMAIL PROTECTED]): > Dear Debian developers, I'm not a DD, but maybe my comments will be useful [...] > In case there are problems, please let me know, so that I can correct > them as necessary. * Standards-Version is outdated (check upgrading-checklist.txt file) * debian/pycompat file is missing (`echo "2" > debian/pycompat`) * debhelper should be moved to Build-Depends * You've missed binary-arch rule in debian/rules (see lintian info) * "current, >=2.4" will not work with current dh_python so putting "2.4" in XS-Python-Version header is correct but why do you have hardcoded python2.4 in debian/rules? Please use something like PYTHON=$(shell pyversions -r) and compile with $(PYTHON) instead of python2.4 * remove "Replaces: harvestman (<= 1.4.6-2)" line in control file, it's the same package, right? * why are you using `find -name file | chmod 755` (and similar)? Isn't `chmod 755 file` not good enough? * no need to use sed in order to change hashbang, pycentral will take care of it * IMHO putting docs list in debian/docs file instead of calling dh_installdocs 4x is better idea (BTW: you can do it in one line) -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpOmyeAWnhGi.pgp Description: PGP signature
Re: dh_python and python policy analysis
On Tue, 2006-08-08 at 13:41 +0200, Pierre Habouzit wrote: > Le mar 8 août 2006 00:18, Pierre Habouzit a écrit : > current explicitely says that the package is only built for the current > python version, and not for any other supported in debian. But I don't > like that value for the following reasons: > * it says for what the package is built, whereas other values explain >for which range of python versions the package is build-able, so >semanticaly it's not homogenous ; > * it prevents the packager to explain with which python versions the >package is compatible, as saying 'current' suggests that the package >is now compatible with the current python version, and will always in >the future, wich may be wrong when (if that happen) some python 3.0 >that is not 100% backward compatible should exists ; > * it also give an information we already have as a package that is >built for the current python version should depend upon python-dev >and not python-all-dev ; It's possible to build Python modules for all versions with only python-dev, if they are pure Python modules (feedparser is such a package, its dependency on python-all-dev is extraneous and could be just python-dev). So simply looking at the dependencies is not enough information. > * current has not a constant meaning, as it depends of the state of the >package python-defaults, and not only of the state of the archive >when the package was uploaded. This is IMHO the biggest flaw of that >field value. This is exactly the *point* of the field. It means you can just binNMU packages and support the new version. If we lose this ability we've lost much of the point of the Python transition. Packages with private extensions still cannot make use of anything but "current" to take real advantage of the new policy (things like ">= 2.3" are a lie because they can still only support one version at a time). If you get rid of it, they are back to the crappy situation we were at a year ago. -- Joe Wreschnig <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: dh_python and python policy analysis
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
Re: Obtain Python version number
Le mar 8 août 2006 06:54, Andreas Tille a écrit :
> Hi,
>
> to write a wrapper script I wonder what might be the best possibility
> to find out the version numer of the running python interpreter. The
> wrapper script is of the type
>
>/var/lib/python-support/python${PYVER}/${package}/${realscript}
>
> and I wonder, how I can obtain ${PYVER} according to the version
> of the python binary that is installed as /usr/bin/python.
>
> I tried
>
>PYVER=`python -V 2>&1 | sed
> 's/Python[[:space:]]\+\([0-9]\+\.[0-9]\+\).*/\1/'`
>
> which works in principle but I wonder if there is some other
> reasonable way.
pyversions -vd will answer the short versions (2.3 today)
pyversions -d will answer python2.3
pyversions -s / -vs do the same with the supported versions.
It indeed is the preferred way to obtain those
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpv1yK7V1V9Z.pgp
Description: PGP signature
Re: Obtain Python version number
Andreas Tille writes:
> Hi,
>
> to write a wrapper script I wonder what might be the best possibility
> to find out the version numer of the running python interpreter. The
> wrapper script is of the type
>
>/var/lib/python-support/python${PYVER}/${package}/${realscript}
>
> and I wonder, how I can obtain ${PYVER} according to the version
> of the python binary that is installed as /usr/bin/python.
>
> I tried
>
>PYVER=`python -V 2>&1 | sed
> 's/Python[[:space:]]\+\([0-9]\+\.[0-9]\+\).*/\1/'`
>
> which works in principle but I wonder if there is some other reasonable
> way.
confused; why a shell script, when trying to get the version of the
*running* interpreter. This should be
import sys
v = sys.version[:3]
It's somewhat communicated that this won't break/change upstream.
Matthias
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dh_python and python policy analysis
Le mar 8 août 2006 00:18, Pierre Habouzit a écrit : > § 2.3.3, 2.4.2, 2.5.3, 2.6.2: > *here* the python$version alternative is correct, > because /extensions/ can be used with a '/usr/bin/python' as soon > as the python current version is in their supported range. > > so take the previous algorithm, and add to (2): if current python > version isn't in that range, add an alternative to the pythonX.Y > corresponding to the range lower bound. Meaning that in my test > cases, instead of *SHOULD NOT HAPPEN* you will get: > > python (>= 2.4) | python2.4 > > and in fact, wrt Depends, the algorithm for pure modules or > extensions, private or public is the same. I forgot to explicitely mention that when extensions are in the package, then you have to restrict your 'python' range to the range of the python for which extensions have been built. That seems obvious, but it has to be stated in the policy very clearly. That means that if you ship a .so for e.g. 2.3, 2.4, then your python depends will be: python (>= 2.3), python (<< 2.5) even if the pyversions is 2.1- about debian/pyversions, unlike his brother XS-P-V it does not supports all/current. for python support you have to use sth like 2.1-. current explicitely says that the package is only built for the current python version, and not for any other supported in debian. But I don't like that value for the following reasons: * it says for what the package is built, whereas other values explain for which range of python versions the package is build-able, so semanticaly it's not homogenous ; * it prevents the packager to explain with which python versions the package is compatible, as saying 'current' suggests that the package is now compatible with the current python version, and will always in the future, wich may be wrong when (if that happen) some python 3.0 that is not 100% backward compatible should exists ; * it also give an information we already have as a package that is built for the current python version should depend upon python-dev and not python-all-dev ; * current has not a constant meaning, as it depends of the state of the package python-defaults, and not only of the state of the archive when the package was uploaded. This is IMHO the biggest flaw of that field value. so IMHO the "current" value should be documented as an internal pycentral value, and should not be recommended to be used for other ways of python packaging. OTOH, I thing "pysupport" should also support "all" as it's prettier than 2.1- and more explicit to the packager, and then it could go into the policy as a recomended value in that case. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpiVolufOJDz.pgp Description: PGP signature
