Re: Experimental slink python and jpython packages
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.
Reply to: