Re: python-debconf, Byte compilation and other questions
On Sat, 2003-04-19 at 08:09, Matthias Klose wrote:
> Bastian Kleineidam writes:
> > On Fri, Apr 18, 2003 at 12:25:08PM +0200, Tim Dijkstra wrote:
> > > On Fri, 18 Apr 2003 11:22:11 +0200
> > > Luca - De Whiskey's - De Vitis <luca@debian.org> wrote:
> > > > file:///usr/share/doc/python/python-policy.txt.gz (that is shipped
> > > > with the "python" package).
> > >
> > > Maybe it's a good idea to put this up the 'developers conner'
> > > website along with all the other policy documents? At the moment it is
> > > hard to find it if you don't know where to look.
> >
> > Yup, I think its time for python-policy to move
> > a) on the Debian website
> > b) into debian-policy (along with the Perl policy)
>
> I just wanted to wait for the "extended" python-central, which handles
> "program packages" like mailman as well. Not sure who began to write
> this ... ;-)
I've had my finger in this pie for a while, but haven't done anything
for a while. There are a few things that need to be resolved in the
Python policy, but I don't think this should prevent it from moving into
the "official locations"... call it rev1, and when we resolve the
issues, it can become rev2.
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.
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).
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.
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).
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...
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.
Random thoughts:
'dpkg-reconfigure python-foo' should re-symlink and recompile python-foo
for every supported version of python. Should this also remove
symlinks/*.pyc's for pythonX.Y packages that have been removed?
'dpkg-reconfigure pythonX.Y' should re-symlink and re-compile every *.py
that needs to be compiled by pythonX.Y. This could be done by calling
dpkg-reconfigure on every package that depends on pythonX.Y (or python
if python depends on this pythonX.Y?), but this would also re-compile
these packages for other supported pythonX.Z's.
'dpkg-reconfigure python' should re-symlink and re-compile every *.py
that depends on the default python. Should this just be call
dpkg-reconfigure for the corresponding pythonX.Y?
'dpkg --remove pythonX.Y' should un-symlink and remove *.py's for all
packages that supported this version of python. Perhaps do this by
calling dpkg-reconfigure for those packages in the postrm script? This
will trigger re-compilation for remaining supported pythonX.Y packages.
'dpkg --remove python' shouldn't need to do anything special, as any
packages that depended on it should have been cleaned up by the removal
of the corresponding pythonX.Y and packages that depend on only python.
'dpkg --install pythonX.Y' needs to symlink and compile every package
that supports pythonX.Y. dpkg-reconfigure them?
The beauty of dpkg-reconfigure is it doesn't rely on internal knowledge
of dpkg or the individual packages. It allows each package to do
whatever it wants in its postinst/prerm scripts and have them called
whenever the "python status" of the system changes.
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.
--
----------------------------------------------------------------
Donovan Baarda http://minkirri.apana.org.au/~abo/
----------------------------------------------------------------
Reply to: