Re: Experimental slink python and jpython packages
Gregor Hoffleit wrote:
>
> On Mon, Oct 12, 1998 at 08:34:19PM +0200, Matthias Klose wrote:
> 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.
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.
> - 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.
> > 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.?
> 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
Reply to: