Re: python-debconf, Byte compilation and other questions
Donovan Baarda writes:
> The things that need resolving, in no particular order;
>
> 1) moving /usr/lib/python* into /usr/share/python*. I consider this low
> priority, but something that should be done one day. There are possibly
> some issues with separating binary extension modules from .py python
> modules that would to be resolved.
-1
As we change the search order, I will wait until upstream applies this
(or at least discussed it). The right way here seems to write a PEP.
> 2) python-central style support for pure-python modules that support
> more than one version of the default python package. The current version
> of python-central can already do this, but it is not in the standard
> yet. I'm not sure if it should be standard untill it suppprts 3).
+1
> 3) python-central style support for python programs that support more
> than one version of the default python package. In particular, this is
> for packages that have "non-public" python modules that are not
> installed in /usr/lib/python/. Currently python-central does not do
> this.
+1
> After having contributed to python-central, I'm still not sure it's the
> best way to do things. It would be nice to avoid having a separate
> package just for python installation scripts. However, it is the only
> way I can think of to have common installation scripts available to all
> python packages without requiring the installation of "python" (ie,
> python1.5-foo only requires python1.5, why should it require python
> (2.1), and hence python2.1, be installed).
what is wrong to have a default python version installed? Many
packages already use python, so it's likely to be installed on a
machine.
> The only alternatives are to have something like dh_python replicate the
> required functionality in every package's postinst/postrm scripts.
> Perhaps a variant of this would be to provide the supporting scripts in
> every pythonX.Y package. Hmmm...
-1.
> If every python package ensured that it symlinked (if required) and
> compiled it's .py's for every installed and supported version of python
> in it's postinst, then doing a 'dpkg-reconfigure -p critical <package>'
> should re-compile the package. There must be ways to use this in scripts
> to ensure correct installation-removal of packages.
[...]
hmm, how does this work for packages like mailman and zope, where more
than recompilation is done in the scripts (debconf configs ...)?
I don't want be asked these questions when I upgrade python.
> The problem of dpkg-reconfigure is it brute-forces everything without
> taking into account the specifics of what the "python status" change is.
> Perhaps a better way to do this is to instead just call the package
> .postinst scripts, adding a few extra "context cue" parameters to tell
> the package what has happened. For example call
> "/var/lib/dpkg/info/python-foo.postinst configure pythonX.Y" when
> pythonX.Y is installed and "/var/lib/dpkg/info/python-foo.prerm
> pythonX.Y" when pythonX.Y is removed.
Then we are at a point, where we need a <package>.python file (maybe
in dpkg format), which contains the python specific meta information.
Matthias
Reply to: