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