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

Reply via email to