On Sun, Sep 29, 2002 at 12:26:30AM +0200, Bastian Kleineidam wrote:
> Hi,
>
> uploaded the new version 0.4 at
> http://people.debian.org/~calvin/python-central/
>
> python-central (0.4) unstable; urgency=low
>
> * renamed register-python-package to python-register, this way
> its prefixed with "python" (and its shorter ;)
> * add options to enable/suppress the compiling of .py[co] files
> * add a new command "python-compile" to compile single python
> files
> * Added a separate section in python-register.1 for python programs;
> also give an example.
>
> -- Bastian Kleineidam <[EMAIL PROTECTED]> Fri, 13 Sep 2002 22:17:45 +0200
I've just had a look at this and it looks good. It perfectly meets the
requirement of allowing pure python module packages to support multiple
pythonX.Y python packages simultaniously.
The only problem is we are still missing something. We still can't easily
support pure python _program_ packages that work with multiple versions of
(the default) python.
Programs like mailman have large mailman specific modules that are used only
by the mailman program. The mailman program doesn't need to support multiple
pythonX.Y packages simultaniously, just multiple versions of the default
python. This is in many ways a simpler requirement than what python-central
solves, but we still haven't got it covered.
Programs like mailman put their modules in their own /usr/lib/mailman
directory. One way that mailman _could_ support multiple pythonX.Y packages
it to have the packager move _all_ the modules into a
/usr/lib/python/site-packages directory and then use python central.
However, this is overkill for mailman because it doesn't need to support
python2.1 and python2.2 simultanously, just the default python. It is also
hell for the packager.
The only problem programs like mailman have is if the default python
upgrades after they are installed, they need to be recompiled. The best way
to handle this is to have the default python packages run dpkg-reconfigure
on all installed packages that depend on python.
This could be added to python central. Currently it auto-detects whether a
python module or pythonX.Y package is being installed by looking at the
package name, and behaves accordingly. All that needs to be added is to have
python-central check for the package name "python", and have it do the
dpkg-reconfigure for all packages depending on python. We then have the
default python packages "register" themselves using python-central.
Now some random thoughts;
finding all packages that depend on "python" is non-trivial using only dpkg.
Something like dpkg-awk, grep-dctrl, or python-apt make it much easier, but
do we want to depend on them? The old "registry" idea would have made this a
little easier, but I still prefer using the dpkg database to find this kind
of info.
Does dpkg-reconfigure actually run the postinst script? Does it do it in a
way (right parameters etc) that would make exising python packages
re-compile properly?
Is a dpkg-reconfigure overkill? We only need to recompile the *.py's. Do
some packages really need to go through a dpkg-reconfigure anyway? What if
they are using debconf options for things like "compile modules"?
We only need to reconfigure/recompile when the default version of python
upgrades to a different version of python, not minor package upgrades. Is
there any way we can detect this and avoid un-necisary recompiles?
Should python-central be providing compile scripts for use by all python
packages? Should we be making use of these scripts manditory in the
Python Policy? If it was then we should be safe using these scripts to
recompile packages instead of using dpkg-reconfigure. But would it be any
better? Is compiling in postinst scripts so trivial as to not need support
scripts?
Another thing I noticed, the man pages are now recommending using;
Depends: python (>=2.1)
Conflicts: python (>= 2.4)
Doesn't the policy have;
Depends: python (>=2.1), python (<<2.4)
I think these mean the same thing, but has the policy changed for some
reason? I actually think that "Conflicts" is less ambiguous...
Pending feedback/ideas whatever, I can code something up to do this. I
probably favor using python-apt (if it can actualy do it) or grep-dctrl to
do the package lookup stuff, but can do it manually if this is a problem.
--
----------------------------------------------------------------------
ABO: finger [EMAIL PROTECTED] for more info, including pgp key
----------------------------------------------------------------------
