7;t take much more than changing a few
directory references and a recompile -- if a package needs more work
than that to build it for 2.0, it probably would have needed that work
anyway.)
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
of /usr/lib/python1.5, if
nothing else.
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
postings is a good idea? stop, please! I'm on the mailing list, I
don't need to see it again...
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
just swap versions.
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
ge but run by a normal user -- the new
.pyc/.pyo couldn't be written anyway. Thus, if the .pyc/.pyo files in
the package were compiled with 1.5, 2.0 would have to recompile the
.py source on every import, or vice versa.
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
have all of these
available at once, even though most people will just get by with 1.5
or 2.0, just like some systems need all four emacsen while most people
just pick one.)
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
source. The standard
module "dis.py" might be useful to look at as well (it's a bytecode
disassembler).
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
mpilation of .so's) of packages that use the
distutils. If distutils usage becomes common (and I see no reason why
it wouldn't) this could enable Python users to install upstream
packages with the full support of the Debian infrastructure, without
waiting for someone to package them as a .deb.
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
usr/lib/...
--Rob
p.s. please everyone, stop sending private copies of mailing list
posts
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
Moshe Zadka <[EMAIL PROTECTED]> writes:
> On 15 Nov 2000, Rob Tillotson wrote:
> > Moshe Zadka <[EMAIL PROTECTED]> writes:
> > > This isn't true. Python 1.5.2-compiled extensions will work just fine
> > > with Python 2.0.
> >
> > Hmm, they
r that version's
library, no matter how the .pycs are supplied.
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
Python version, there is
/usr/lib/site-python. While python-base does not appear to create
this directory, it is part of the default sys.path (in the current
1.5.2 packages) and there are at least two packages (reportbug and
dpkg-python) which live there.
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
eems to be
right on target. So the only one at issue is task-python-dev, which
is explicitly a catch-all.
Maybe in woody we can have some more task-python-* packages for more
kinds of Python programming... task-python-scientific and
task-python-sql might be good ones, for example. But for now, the
current ones are fine.
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
source (under a license like that of the Python
interpreter).
I don't expect the packaging process to take very long, as the
upstream source is relatively compact and much like every other Python
source package out there.
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
iles corresponding to each Python source file, preferably by
compiling in the postinst.
4. The Python interpreter and most standard libraries are provided
by python-base; all Python related packages should depend on it.
And that's about all...
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
potato
working until the dependencies are fixed, but it should not be
necessary to keep those dummy packages around forever (and certainly
all the third-party stuff should be fixed by the next release).
- --Rob
- --
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
-BEGIN PGP SIGNATURE-
Version:
(palmpython and palm-doctoolkit).
--Rob
--
Rob Tillotson N9MTB <[EMAIL PROTECTED]>
17 matches
Mail list logo
