I told to stay tuned... And now here I am, still waiting for your upcoming Debian Python Policy... But I see some part of it, at least...
On Tue, 15 Sep 1998, Gregor Hoffleit wrote: > Hi, > > - removal of python-net and python-misc > - instead, a new package python-lib > Nice, I think it was about the time to condense the python distribution files... > > - python-lib is Architecture: all; it's the architecture-independent part > of python-1.5.1/Lib. > - /usr/share/python instead of /usr/lib/python1.5 > - /usr/lib/python1.5 has the architecture-dependent stuff like > lib-dynload and config (this should probably be /usr/lib/python/). > I'm still unsure if it wouldn't be better to stay closer to upstream behaviour > > - sitecustomize should be a conffile and therefore live in /etc/python/. > This is right > > - Not yet done: Change Makefile.pre.in so that it installs in the correct > places. > I think it is mandatory, if we want to change the default paths > > - Not yet included, the code exists: Build a shared libpython I think it would be of some use (at least) to those willing to use stuff like apache-module. > > > The layout with /usr/share/python and /usr/lib/python has many advantages > for Debian, but also a few drawbacks: It makes it impossible to install > two different Debian python versions at the same time (not possible > yet with the current layout; do we really need this ???). It drives us > away from the upstream python layout. Still I think the advantages (much > easier upgrade paths; let the Debian packaging system handle versioned > dependencies) are more important. > I should think a lot more before replying, but we wouldn't lose dpkg dependancies even if we stayed closer to upstream... > > Then, there's the question where and how to install Debian Python add-on > packages. I'd like to adopt a mechanism similar to emacen-common, where [...] > Python add-on packages: e.g. /usr/share/site-python or > /usr/share/python/site-packages (for architecture-independent files) > or /usr/lib/python/site-packages or /usr/lib/site-python or even > /usr/lib/python1.5/site-packages (for architecture-dependent or binary > packages). Finally, how to handle "old-style" packages ? > For old style packages, I think^H^H^H^H^H am almost sure we should use the .pth solution, and make each of them reside in a separate subdirectory. I don't understand why don't you like a (not buggy) compileall.py, which would leave alone .py files elder than their corresponding .py[co]; and then, does Jpython use a different extension? If so, wouldn't we need a compileall mechanism to compile stuff present before jpython install? A problem with your proposed lib - share split could come from mixed binary/python packages like PIL... I think it would be a small clearness advantage being able to put the whole package inside a single directory, but then /usr/share should only contain arch-independant stuff... > > I really would like to introduce these changes with slink. > I fear we are a bit late... seems slink is about to freeze (without a working pam, which is really sad for me!). A final comment: I really like the python-xxx convention to name any python add-on package much more than libpython-yyy, but any one (I told one!) would do... Yours, l.
