Re: Experimental slink python and jpython packages
On Tue, Oct 13, 1998 at 04:13:40PM +0300, Arto Astala wrote:
> > 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.
>
> Apart of other changes, isn't it possible (and reasonable) to
> move from python-net & python-misc to python-lib if it has
> replaces, conflicts, provides: python-net & python-misc ?
> That way some of the changes could be done earlier, even if
> there is no time for all of them.
It should be possible, but it isn't: dpkg won't accept "Provides" with
versioned dependencies. Dependencies like
Depends: python-misc (>= 1.5), python-net (>= 1.5)
won't be satisfied by a "Provides: python-misc". This is a bug/known
problem in dpkg.
So I guess I'll let python-lib provide python-net and python-misc, but
it won't help for most packages.
> > > 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
>
> > 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.).
>
> This actually depends on how space friendly we want to be
> for sys-admins. If we think that our cache can collect
> large amount of rarely used stuff, then /var/cache is
> the polite thing to do. If we think that this will not be
> a problem then it is not needed. We can, naturally, offer
> any other .pyc etc. purging mechanism instead, if needed.
>
> BTW, what happens if there is no writable dir for .pyc etc.?
Without having inspected import.c in depth: If it imports a module,
Python tries to find the module along PYTHONPATH. For every directory
in PYTHONPATH, it looks for a source file (module.py), a compiled file
(module.pyc resp. module.pyc) as well as a module/ subdirectory with a
__init__.py file).
If only a compiled file is found in a directory, it is loaded.
If only a source file is found, it is loaded and parsed. Python then
tries to write the compiled file into the same directory where the
source was found. If this fails (e.g. since the directory is not
writable), this is silently ignored (try "python -v" to see the error
message).
If both a source and a compiled file are found, the compiled file is
checked for its validity (the source file must not be more recent). If
it's valid, the compiled file is loaded. If it's invalid, the source
is loaded and parsed, and Python tries to replace the compiled file
with a new one, also silently ignoring error.
[Btw, note that the order of the directories in PYTHONPATH takes the
highest priority: If PYTHONPATH=/a:/b, and there's a /a/module.pyc,
/b/module.py will never be loaded, even if it's more recent!
Therefore, /b/module.py will never be compiled.]
It's not reasonable to give anybody but root write-access to
/var/cache/python, it would be a security hole. The "cache" would have
to be maintained by some sort of root script.
Therefore, either we had to be sure that the files in
/var/cache/python are always up to date wrt to the sources in
/usr/share/python, or we had to tweak Python/import.c to consider both
directories at once, which is no good idea IMHO.
Gregor
Reply to: