On Mon, May 19, 2008 at 11:20:10PM +0000, Ben Finney wrote: > Floris Bruynooghe <floris.bruynooghe@gmail.com> writes: > > > On Mon, May 19, 2008 at 12:49:11PM +0200, Josselin Mouette wrote: > > > Python-central links modules at their original places while > > > python-support puts them in /var/lib to follow the FHS. > > > > "/var/lib : Variable state information [...] State information is data > > that programs modify while they run, and that pertains to one specific > > host." [2] > > Agreed. Complied-one-time-on-install Python library code is not > "variable state information"; rather, it is an unchanging (modulo > package-system changes) part of the system, so belongs in /usr > somewhere. pysupport puts a farmlink in /var/lib so that .pyc files that are /var material are in /var/lib. The .py files live in /usr/share. pysupport is supporting FHS to the letter. On the other side, pycentral puts things where they were installed, and pyc along them. That's why you find _totally_ arch indep .py files live in /usr/lib/python2.5, because they must go along with .pyc files and puting them in /usr/share where they belong would break because of .pyc files. Note that the real issue here for real is that python isn't capable of using an alternate shadow path hierarchy to store .pyc files like e.g. fontconfig does. That's why pycentral/pysupport have to do really scabrous things in the first place. pysupport is forward compatible with such a possible change in python, it would _just need_ to stop doing its symlink farm and keep byte compiled stuff in /var/lib like it does right now. -- ·O· Pierre Habouzit ··O madcoder@debian.org OOO http://www.madism.org
Attachment:
pgpV3cckQoG9Q.pgp
Description: PGP signature