[anatoly techtonik, 2009-08-04] > Before discussing your proposal I would really appreciate if somebody > from insiders could describe situation in Debian Python in all > possible detail including the history of development. I believe that > this piece of work is absolutely necessary, because the problem of > repackaging Python packages for Debian and maintaining integrity > between installed packets, packages and Python versions is too complex > to keep every detail in mind unless you can devote your full time to > the problem.
Short? Our goal is to support more than one Python version at the same time if having one Python in the archive is not possible (f.e. when there are applications that still require older Python). We do that currently by shipping Python extensions for all supported Python versions in the same package and byte compiling Python modules at install time for all installed (and supported) Python versions (sharing .py files whenever possible). Read [1] and then [2] if you want more details (yeah, [1] is not official[3] as there were some differences of opinion :-) - I hope it will be easier to finally update the official policy if this proposal will be accepted) [1] http://people.debian.org/~srivasta/manoj-policy/ [2] http://lists.debian.org/debian-python/2009/02/msg00061.html [3] http://www.debian.org/doc/packaging-manuals/python-policy/ > You say that attempt to merge -cental and -support failed, but didn't > mention why. attempt is here[4,5], the reason why it failed is here[6] [4] http://lists.debian.org/debian-python/2009/02/msg00083.html [5] http://lists.debian.org/debian-python/2009/02/msg00099.html [6] http://lists.debian.org/debian-python/2009/03/msg00015.html > You say that current tools have problems that occur at > install/upgrade time, but do not mention these problems explicitly. So > it is impossible to say whatever your ideas solve current problems and > won't add new. see [7] and [8] for some of them. I tried to help many users (including co-workers and #debian-python channel guests) that had ImportError problems I couldn't reproduce on my machine and usually the solution was to reinstall related Python packages (due to missing symlinks or symlinks from older package versions not properly removed at upgrade). I had that problem once on my own system as well, couldn't reproduce it later (and thus couldn't really write a sensible bug report). Right now upgrading from Lenny's pycentral based packages will fail if list of files will be different in Squeeze' version (due to moving to pysupport or dropping "nomove" feature or simply by providing different module names) unless you provide a preinst script that will remove old files. Another issue is the fact that packages with common namespace have to use the same tool (search f.e. for twisted issues in the mailing list or BTS) as otherwise they will end in different directories (i.e. will be reachable from different locations of sys.path) and Python will not recognize that. Yet another issue is the pysupport namespace feature that actually causes more problems than it solves (see f.e. #459446 or #536739) Also, during upgrades, daemons downtime should be as short as possible and since Python modules are right now not available after unpacking debs, it's hard to accomplish it. You also have to do some extra work to be be able to start them during installation. [7] http://bugs.debian.org/python-central [8] http://bugs.debian.org/python-support > Referencing rtinstall/rtupdate/rtremove scripts is cool for a seasoned > Debian developer, but for a Python developer it means nothing. In > other words - not only Python things are obscure for Debian > developers, but Debian stuff is also a mystery for Python masters, so > these things should be explained symmetrically for both communities. > The chances for Debian Python Packaging experts to pop up are > magnitude less if we won't explain the situation in detail. see chapter 6[9] of "Manoj's policy"[1] [9] http://people.debian.org/~srivasta/manoj-policy/x673.html > Now about the proposal (from newcomer's point of view): > dh_python is a shell script -- I have a strong belief that Python > package automation scripts should be written in Python, there is no > need to learn bashes when you program Python - do not expect that > package maintainers will be able to debug their scripts in shell > language. I will write them in Python, old dh_python is written in Perl /bin/sh as dh_python's shebang is not that bad idea, BTW :-) [...] > May I ask a question - is there a difference between installation of > Python Modules and Python Applications? yes, Python applications should be installed in private locations (i.e. outside site-packages) whenever possible (to avoid name conflicts and unnecessary symlink burden). > Does the problem set you are > trying to resolve with this proposal include the difference? Have you > considered distributing Python Applications via virtualenv? How this > proposal handles virtualenv installations? virtualenv is great solution if you want to use different module versions than the ones provided in debs and don't want to break other parts of your system[10] (upstreams usually don't know how important it is to keep the API stable and Python doesn't have sonames equivalent[11])... but security team would hate us if we'd use it in Debian packages (fixing bugs in one package is much easier than fixing the same bug in dozens of them) [10] all these guys that suggest "sudo ez_install ..." should be forced to work as sysadmins until they'll apologize (a week will probably be enough ;) [11] you can rename the module of course (like jinja -> jinja2), but only one upstream author did that in packages that I maintain - thanks Armin!). Search for python-cherrypy{,3} issues for more details. > In conclusion my opinion is that problem set is not defined well > enough to propose a solution or estimate if it will be effective both > for current flow and for future ideas. I would start from wiki. The main reason for my proposal is to end policy wars, make maintaining Python packages easier and have Python 2.6 and 3.1 finally in unstable. -- -=[ Piotr Ożarowski ]=- -=[ http://www.ozarowski.pl ]=-
signature.asc
Description: Digital signature
