On Mon, Oct 12, 1998 at 08:34:19PM +0200, Matthias Klose wrote:
> Gregor Hoffleit writes:
> > Hi,
> >
> > I placed new experimental packages of python and jpython on my private
> > web page, http://www.mathi.uni-heidelberg.de/~flight/debian-private/.
> >
> > Sorry that I still not managed to put together the proposal for a Debian
> > Python policy. If you look at the packages, you'll get the idea for a few
> > modifications that I'd like to make before the slink release:
> >
> > - /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/).
>
> Back from my vacations, I am not yet up to date ... What was the date
> of the code-freeze for slink? Is there time enough to convert all
> other packages?
Several threads on debian-devel hinted that the freeze will happen
somewhere between one week ago and one week ahead. Although I asked
two times on debian-devel when exactly it will happen, I got not a
single reaction.
We don't know a timeline for the freeze, and there was not very much
reaction to the packages above. I guess that leaves us with two
options:
1.) Play safe. Stick with the current scheme for slink. I'll upload a
new revision 1.5.1-5 with minor fixes only (all official patches
applied).
2.) Play risk. Adopt a new scheme similar to my proposal, e.g.
- Remove python-net, python-misc; new package python-lib. This would
break a few packages' dependencies; those had to be rebuilt.
- perhaps new package python-common which manages add-on packages
(cf. emacsen-common). Use could be optional; no package had to be
rebuilt.
Anyway, most python-related packages had to be rebuilt for slink if we
choose 2; no major things, just fixing the postinst scripts
AFAICS. This easily could be done as NMUs. This should be no problem;
the real question is if we want to try this in slink.
> > 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
> > every package registers itself with the system. The install-python
> > program would byte-compile the files for the installed Python systems
> > (i.e. with "python", with "python -O" and perhaps with "jpython"). IMHO
> > this is much better than the current python
> > /usr/lib/python1.5/compileall.py hack that will have to be updated with
> > every new major release).
>
> I like this idea (but I don't see what needs to be updated with the
> current approach). This script shouldn't contain any location, but
> information of architecture dependent and independent files.
>
> And: Shouldn't generated files be placed in /var/cache/python?
Hmm. Maybe. FHS says about /var/cache:
"5.2 /var/cache: Application cache data
/var/cache -- Cache directories
|
+-- fonts Locally-generated fonts
+-- man Locally-formatted manual pages
+-- www WWW proxy or data cache
+-- <package> Package specific cache data
/var/cache is intended for cached data from applications. Such data is
locally generated as a result of time-consuming I/O or
calculation. The application must be able to regenerate or restore the
data. Unlile /var/spool, the cached files can be deleted without data
loss. The data should remain valid between invocations of the
application and rebooting the system.
Files located under /var/cache may be expired in an application
specific manner, by the system administrator or both. The application
should always be able to recover from manual deletion of files
(generally because of a disk space shortage). No other requirements
are made on the data format of the cache directories."
(The files in /var/cache need not be shareable or
architecture-independent, although this would be the case for
python/jpython).
Pretty much a description of .pyc, .pyo and $py.class files.
Still, I wonder if it's reasonable apart from strict FHS compliance
(the emacsen don't use /var/cache either for their .elc files) and if
it's technically possible (we would have to put both /var/cache/python
as well as /usr/share/python in PYTHONPATH, same site-package etc.).
I won't have time this week to work on this stuff. If the freeze will
be happening this week, I guess we'll have to choose 1). If there's a
little more time (e.g. til end of October), I'd like to go with 2), if
most of you agree.
Gregor
--
| Gregor Hoffleit admin MATHInet / contact HeidelNeXT |
| MAIL: Mathematisches Institut PHONE: (49)6221 56-5771 |
| INF 288, 69120 Heidelberg / Germany FAX: 56-3812 |
| EMAIL: [EMAIL PROTECTED] (NeXTmail) |
