On Thu, 2003-08-07 at 18:44, Alexandre Fayolle wrote: > On Thu, Aug 07, 2003 at 12:58:25PM +1000, Donovan Baarda wrote: [...] > > Python applications using the default Python with their own modules not > > in /usr/lib/site-python... not an issue?
Actually... I think I prefer /usr/lib/python/site-packages rather than /usr/lib/site-python because that way the directory structure mirrors that for the /usr/lib/pythonX.Y "specific version" tree. > They are expected to configure their own PYTHONPATH, are they not? Yeah, the issues with the current policy and this is that there is no way to re-compile these modules when the default python changes. > > Making sure all the pyc's are re-compiled when the default python is > > updated. > > Yes. Should not be too difficult. There are tricks here that make it a little harder than you would expect. Because deb's don't support "triggers", the python package will have to find all the *.py's that need compiling itself. There are two ways I can see to handle this; 1) have all packages put .py's in a suitable place (/usr/lib/python) so they can be re-compiled. But this breaks Python programs that have their own modules in some other place. 2) Have the python package identify all the packages with py's that need to be recompiled, then "tell them" to recompile themselves by executing something that triggers the package's recompile scripts (dpkg-reconfigure or the .post-inst, or something). Identifying the .py's that need recompiling is actually pretty tricky too.. you need to identify all packages that depend on "python" with "*.py" files. > > A brute force approach is to have the python packages post-inst run > > "dpkg-reconfigure" over every package that depends on "python", and > > require that packages recompile their pyc files on a "dpkg-reconfigure". > > This has the advantage of "notifying" all these packages when the > > default python has changed so they can do other stuff if they need to. > > This would be nice, but packages will take some time to catch up. I think a dpkg-reconfigure re-runs the post-inst scripts which should already compile stuff. We could call the post-inst scripts directly, but dpkg-reconfigure might do other stuff that is more package friendly. I don't think any packages apart from "python" will need changing to support this (hence why I suggested it, despite it being a bit of overkill) > Another thing we should take care of is packages which used to be pure > python in version N, and include C extensions in version N+1. The > packages for N+1 should be versioned, but how can we provide a nice > upgrade path? In order to be sure not to break anything, we would have > to make the new python-foobar package depend on python2.X-foobar for X > in (1,2,3). Example use case; Up to and including python (2.1) we had; python-foo (1.1) with files in /usr/lib/python Depends: python Now we have python (2.2) and a new upstream release of "foo" python2.2-foo (2.1) has a C exension in /usr/lib/python2.2 Depends: python2.2 We need to make the following packages; python2.1-foo (1.1) with files in /usr/lib/python Depends: python1.5 | python1.6 | python2.0 | python2.1 Provides: python1.5-foo, python1.6-foo, python2.0-foo Replaces: python-foo (<=1.1) python-foo (2.1) as a wrapper for python2.2-foo Depends: python (>=2.2), python (<<2.3), python2.2-foo the "almost version idependent" python2.1-foo provides support for python1.5, python1.6, python2.0, and python2.1. The python2.2-foo provides support for python2.2. The new python-foo wrapper provides support for the default python (2.2). Because the python path for python2.2 lists /usr/lib/python2.2 before /usr/lib/python, python2.2 will grab the correct C extension version, but other versions of python will use the old pure python packages in /usr/lib/python. Hmmm... this has implications that affect what version the .pyc's for python2.1-foo in /usr/lib/python should be compiled for. They should _not_ be compiled against the default python, so we can't just compile-all in /usr/lib/python when the default python package changes. It seems each individual package should be responsible for compiling it's own *.py's with an appropriate version of python, even in /usr/lib/python. We can't have the "python" package handle it directly. Here's a suggestion; Each package that depends on any version of python or pythonX.Y must compile it's own *.py's in its postinst and remove its own *.pyc's in its postrm using a suitable version of python. Packages that support the default python should compile using /usr/bin/python (provided the version is OK). Packages that support multiple pythonX.Y's should compile using that highest installed version of pythonX.Y that they support. The "python" package's postinst and postrm scripts should find all the installed packages that depend on "python" and get them to re-run their postinst scripts, either by calling the postinst scripts directly or running dpkg-reconfigure. Each "pythonX.Y" package must do the same thing in it's postinst and postrm scripts for all packages that depend on "pythonX.Y". > The last point is how to write dependencies on packages which are ot > available on all python versions. For instance python-docutils needs > python-xmlbase and python-difflib. python-xmlbase exists for python2.1 > and 2.2 but not 2.3, and difflib exists for 2.1, but not 2.2 or 2.3. How > should the dependencies be written ? >From this it seems python-docutils will only work for python2.1... yeah? Try the following set of dependencies; Package: python-docutils Depends: python (<<2.2) | python2.1 | python2.0 | python1.6 | python1.5, python-xmlbase, python-difflib Provides: python2.1-docutils, python2.0-docutils, python1.6-docutils, python1.5-docutils Package: python-xmlbase Depends: python (<<2.3) | python2.2 | python2.1 | python2.0 | python1.6 | python1.5 Provides: python2.2-xmlbase, python2.1-xmlbase, python2.0-xmlbase, python1.6-xmlbase, python1.5-xmlbase Package: python-difflib Depends: python (<<2.2) | python2.1 | python2.0 | python1.6 | python1.5 Provides: python2.1-difflib, python2.0-difflib, python1.6-difflib, python1.5-difflib Note even though docutils contains modules that work with python2.2, it depends on difflib that doesn't, so we can't have a package that supports python (2.2). The versioned alternative dependency on "python" is there to ensure the pyc's are compiled using the default python, provided it is of a supported version, instead of the highest pythonX.Y. Without it, these packages will not get "notified" when the default python version changes. -- Donovan Baarda <[EMAIL PROTECTED]>
