On Thu, Nov 23, 2006, Josselin Mouette wrote: > > I still think there's currently no protection against silent breakage > > in python-support. Packages are still ./configured to install python > > modules into /usr/lib, but this does not reflect the runtime location > > of files. This is particularly a problem for plugins mechanisms. > Only for plugins that aren't relocatable. This can be worked around in > the ./configure, but a better solution is to avoid such mechanisms.
Whatever the solution, it must not impose source level changes to valid uses of the python infrastructure. Especially going to each individual upstream to explain that 1) they are doing something which doesn't work under Debian but works everywhere else and we would like to fix it and to explain that 2) we ./configure with one path but we move the files to a different path later on ... this would be relatively time consuming, and might even introduce incompatibilities between Debian and other distros. If instead we start saying at ./configure time that our Debian python needs Python stuff in /var/lib/python-support, then nothing would break and we would only need to convince upstream that we need support for ./configurable Python install path when this is missing. > > I suppose it would be enough to 1) document the problem in the > > python-support documentation 2) recommend people to ./configure with a > > python path of /var/lib/python-support/pythonX.Y 3) stop moving files > > from /usr/lib/pythonX.Y into /var/lib/python-support. 3) is obviously > > for the long term. > The real long term solution is to have python look for byte-compiled > files directly in /var/cache/python/$hash, just like fontconfig does. > Having done things right from the beginning would have saved a lot of > trouble. That's the very long term solution which involves modifying python (and such a low-level change could IMO happen only upstream), so I wont hold my breath. However, documenting proper Python Policy usage in Debian sounds more feasible, especially given the age of python-support or the latest python policy. For example, if documented now, people could start converting their packages slowly, and write new packages with this in mind, and the next policy version would require it. -- Loïc Minier <[EMAIL PROTECTED]> 10 SIN 20 GO TO ROBOT HELL -- Temple of Robotology