[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 ]=-
Attachment:
signature.asc
Description: Digital signature