Lars Wirzenius <[EMAIL PROTECTED]> wrote:
> While we're listing personal preferences, I'm firmly in the camp that
> belives Python should create .py[co] files only when explicitly asked,
> never implicitly just by running programs. That way, whenever someone
> explicitly has the created, they're al
On Wed, Jan 10, 2001 at 11:01:40PM +0100, [EMAIL PROTECTED] wrote:
> What I want is if we allow both Python 1.5 _and_ Python 2.0 to be
> So we need
> ...
No, we don't. Python already installs its modules into
$PREFIX/lib/python$VERSION
I've already built a Python 2.0 package with installs a
On Wed, Jan 10, 2001 at 12:32:02PM -0800, Neil Schemenauer wrote:
> On Wed, Jan 10, 2001 at 11:01:40PM +0100, [EMAIL PROTECTED] wrote:
> I've already built a Python 2.0 package with installs along side
> of the regular Debian Python package.
Someone asked for them so here they
On Mon, Jan 15, 2001 at 08:33:19PM +0100, [EMAIL PROTECTED] wrote:
> I am distributing Python programs under the GPL. So is this sentence
> above telling me that all users are not allowed to use my GPLed programs
> with Python 2.0?? What about previous versions?
IANAL, but:
This only causes a pro
On Tue, Jan 16, 2001 at 11:44:47PM +1100, Peter Eckersley wrote:
> If you listen to CNRI or BeOpen's lawyers (but not Eben Moglen
> & the FSF), you're fine.
Guido has told me that something has been worked out with the FSF
now. Hopefully this stupid issue can be put to rest and we can
all get on
The word from the BDFL himself:
- Forwarded message from Guido van Rossum <[EMAIL PROTECTED]> -
Date: Tue, 16 Jan 2001 23:16:48 -0500
From: Guido van Rossum <[EMAIL PROTECTED]>
Subject: Re: [Python-Dev] [EMAIL PROTECTED]: Our application doesn't work with
Debian packaged Python]
> This
On Mon, Jan 22, 2001 at 02:16:25PM +0100, Jérôme Marant wrote:
> Were did you read about this ?
Guido has told me that the GPL incompatibility is being
straightened out.
Neil
On Mon, Feb 05, 2001 at 04:43:29PM -0800, Rick Younie wrote:
> Has anyone built Python 2.1 alpha 2?
Yes.
> It appears that unicodedatabase.c is missing.
That file has been dead for a while. Perhaps your Modules/Setup
file is out of date.
Neil
On Mon, Feb 05, 2001 at 06:04:21PM -0800, Rick Younie wrote:
> ucnhash.c too? Both are in Setup.dist, commented out.
Yup. Fredirik Lundh did some cool work to prune down the unicode
database even more. The original module some something like 2MB.
Its down to about 200kB now.
> The package bui
On Fri, Mar 23, 2001 at 09:39:07PM +0100, Gregor Hoffleit wrote:
> I wonder if I should debconf-ify python-base and add an debconf option that
> sets a system-wide policy about how to deal with .py/.pyc files. That could
> be one of:
>
> * install both .py and .pyc files
> * install only .pyc
Carey Evans wrote:
> Tom Cato Amundsen <[EMAIL PROTECTED]> writes:
>
> > Excuse me for bugging you about this, but has you heard anything
> > from RMS yet? With the upcoming freeze, it would be nice to know as
> > soon as possible if we will have a GPL compatible python 2.x in
> > woody.
>
> Act
Matthias Klose wrote:
> - new packages names python2.1-foobar
>
> - same package names, but add versioned dependencies: python-foobar (>= 2.1)
>
> The latter will cause some incompatibilities until all python2
> dependent packages are uploaded for 2.1.
I strongly prefer the latter. If people wa
Gordon Sadler wrote:
> I'd just like to comment on this. I installed python2.1 some time ago in
> /usr/local. However this leads to problems. You have to modify some of
> the code (eg PYTHONPATH IIRC) due to using prefix=/usr/local.
Which code is "the code"? The code distributed with Python works
Gregor Hoffleit wrote:
> Sorry ? What problems do you have installing Python 2.1 in /usr/local on
> a Debian system ?
Sometimes /usr/local/bin/python is used instead of /usr/bin/python. For
example, dput uses "#!/usr/bin/env python". Also, its postinst script it
does:
python -c 'from compil
Gregor Hoffleit wrote:
> Binary extension modules depend on the version of Python that they were
> compiled against (a different micro version should be ok, AFAIK).
That's right. Maybe I don't understand the mess we are in now. Can you
explain exactly what it is?
As I understand it, we want to
Gregor Hoffleit wrote:
> Pure Python packages not necessarily would need to be rebuilt (if the
> code was cross-version compatible).
It almost always is. Python tries very hard to remain source compatible
across releases. I've been using Python for 9 years and can only think
of one case were my
Aquarius wrote:
> Especially since "#!/usr/bin/env python" is recommended in the Python
> FAQ (section 4.63 --
> http://www.python.org/cgi-bin/faqw.py?req=show&file=faq04.063.htp). Is
> it bad to use in general, or just bad to use on Debian systems?
Depends. If your writing a script or program to
Mikael Hedin wrote:
> I think the proposed scheme with python2.1 and module2.0 et.al. is
> really ugly and messy.
I agree. Didn't the Perl packagers advise us not to go down this
path?
Neil
Jérôme Marant:
> The major question is: do we still need to ship 1.5.2? Unfortunately,
> the old python seems to be necessary since some old packages are not
> compatible with 2.x versions.
Do you know of any? If you can point them out I may be able to help fix
them.
Scott Moynes wrote:
>
Jim Penny wrote:
> This is not all that simple. python2.1 conflicts with zope2.3.x
> and python1.5 conflicts with zope2.4.x.
In that case I think it's better to create python1.5 and zope2.3
legacy packages for people who can't upgrade.
Neil
Jérôme Marant wrote:
> Neil Schemenauer <[EMAIL PROTECTED]> writes:
> > Do you know of any? If you can point them out I may be able to help fix
> > them.
>
> Zope 2.3x was the most obvious example. I don't know if python-ldap can
> work with 2.x too. All
See here:
http://people.debian.org/~nas/woody/
The source packages I have are:
python_2.1.1
python1.5_1.5.2
zope2.3.3
These create the following binary packages:
python-base
python-dev
python-elisp
python-examples
python-gdbm
python-mpz
python-regrte
Jérôme Marant wrote:
> Would you please comment on this?
Looks reasonable to me.
Neil
Bruce Sass wrote:
> Any program that exists with Python dependent versions will need
> multiple versions of Python packages. Maybe Zope today, who knows
> what tomorrow. Either Debian supports multiple installed versions of
> Python out-of-the-box, or users start jumping through a bunch of hoops
Carey Evans wrote:
> I've had a look at these packages myself. Can you tell us what stage
> they're at, i.e. what still needs to be done, what problems you know
> about and what you want to hear about?
I thought my first message explained that. Mostly the Depends,
Conflicts, Replaces, Provides i
Gregor Hoffleit wrote:
> Have you looked at my experimental Python packages, at
> http://people.debian.org/~flight/python/snapshot/ ? I haven't yet tried
> your packages, but it sounds like you started from scratch ?
No, I based them on your python and python2 packages. I've made quite a
few bug
: [Python-Dev] re-ordering sys.path
To: Neil Schemenauer <[EMAIL PROTECTED]>
cc: python-dev@python.org
> > So, I'm proposition to reorganize the PYTHONPATH like this :
["site-packages first" proposal snipped]
(Why do people write PYTHONPATH when they mean sys.path?)
> Wil
Bruce Sass wrote:
> On Thu, 6 Sep 2001, Neil Schemenauer wrote:
> > Again the package is python-base, not python2.2-base. pydoc depends on
> > python-base_2.1.1 and uses #!/usr/bin/python. I don't see a problem
> > with that.
>
> Except you don't know whi
dman wrote:
> I think the admin should be able to choose which python implementation
> is referred to by /usr/bin/python independent of which python (or
> python-base if you prefer) packages are installed (the alternatives
> mechanism may be a good idea for this). There can be any number of
> reas
I see now that the python2 packages made it into unstable. This is a
mistake IMHO. The Perl guys tryed this and it didn't work. Also, the
name should have been python2.1 not python2. What problem does naming
the packages "python2" solve? It seems like a big pain for everyone
for no gain.
I've
Bruce Sass wrote:
> The python-base package gives me python->python2.1, from Python-2.1.1.
> What happens when I point python to python3.0, will pydoc still work.
What happens when I point /usr/bin/perl to Perl 4? I think I've just
screwed up the system pretty badly. Use /usr/local for site spec
On Fri, Feb 09, 2001 at 10:53:53AM -0500, Michael Tiemann wrote:
> OTOH, if somebody can make a really definitive statement that I've
> misinterpreted the responses, and that 2.x _as_ python should just work,
> and if it doesn't, it's a bug that needs to shake out, I can address that
> with our OS
Gregor Hoffleit wrote:
> Note that the python2 packages are, at this time, legacy.
Okay. What do you think about my plan to have "python" be the latest
version of Python and then have "python-x.y" packages for those people
who need to have older versions?
Neil
Please comment.
Neil
Debian Python Policy
Neil Schemenauer <[EMAIL PROTECTED]>
versi
Mikael Hedin wrote:
> Looks fine to me. I'd prefer /usr/bin/python-X.Y, but that's
> cosmetics, not really important.
It has been pythonX.Y for many years. We should not change it.
Neil
Ricardo Javier Cardenes wrote:
> I think this:
>
> /usr/local/lib/python./site-packages
> /usr/local/lib/site-python
> /usr/lib/python./site-packages
>
> should be the order.
I see not problem with that. It shouldn't make any difference except in
the case you describe.
> And what happene
Jim Penny wrote:
> I just want to ask a couple of questions to make sure that I understand
> this in detail. Suppose python2.1 is installed as python and you
> also have python1.5 installed. You have
> script poo which is invoked via #!/usr/bin/python and
> script bah which is invoked via #!/us
Zooko wrote:
> I got some dependency errors when I tried to install:
Oops, there was some dependency wierdness with python-base and that
screwed up everything else. I've updated my Python packages. Please
give it a try again if you don't mind. Thanks for your feedback.
Neil
Carey Evans wrote:
> By way of example, suppose I have a package "spam" that embeds Python
> 2.1, and therefore depends on python-2.1. spam also uses the "eggs"
> module, and therefore depends on python-eggs, which depends on
> python-2.1 itself.
>
> Now Python 2.2 is released, and eggs is recomp
Donovan Baarda wrote:
> First off, you need to clarify what you are attempting to achieve. There are
> three possibile aims as I see it;
>
> 1) single "official" version of Python in archive/distro.
> 2) multiple alternative versions of Python in archive/distro, only one
> installed at a time.
>
Packages (mostly) conforming to this policy are at:
deb http://people.debian.org/~nas woody/
I've updated a lot of packages. If there is something missing that you
use please let me know. After updating about 30 packages I'm getting
good at it. :-)
Changes from last version (off the top o
Jérôme Marant wrote:
> I browsed the Package file and I've seen some new things in dependencies
> like python-api ones (similar to perl-api I guess).
>
> Coud you explain briefly how they work?
It's easier and less error prone for packages to depend on
python-api-2.1 rather than "python (>=
Jérôme Marant wrote:
> Neil Schemenauer <[EMAIL PROTECTED]> writes:
> > It's easier and less error prone for packages to depend on
> > python-api-2.1 rather than "python (>= 2.1), python (< 2.2)". That's
> > it.
>
> So i don't see
Donovan Baarda wrote:
> On Sat, Sep 29, 2001 at 11:17:19PM -0700, Neil Schemenauer wrote:
> > Donovan Baarda wrote:
> > If you change the major or minor version of Python installed then
> > packages that depend on it must be upgraded. There is no way around
> >
Donovan Baarda wrote:
> Hmmm, but if only "python" can provide python-api-*, then any packages that
> depend on python-api-X.Y will be broken when a new version of python
> providing python-api-X.Z comes out, and no python-X.Y package can be
> compatible with it.
That's right. Packaged modules mu
[Please don't CC me, I'm on the list. I wish MUAs would respect the
mail-followup-to header.]
Donovan Baarda wrote:
> From archive updating point of view, my scheme has a large
> python-X.Y-foo added and a small python-foo updated when python
> upgrades. Your scheme has a large python-foo updated
Carey Evans wrote:
>/> python-2.1 -\
>spam -- > python
>\---> python-eggs ---> python-api-2.1 ---/
spam should depend on python not python-2.1.
Neil
Donovan Baarda wrote:
> Packages like extension modules _are_ tied to a particular version and hence
> should be in a python-X.Y-foo package that installs into /usr/lib/pythonX.Y.
> There would also be an empty package python-foo that simply depends on the
> latest python-X.Y-foo and python pack
Carey Evans wrote:
> In my original example, spam embeds libpython2.1.so. It would make
> sense for this to mean it depends on python-api-2.1, though this isn't
> what the current shlibs file says.
Only "python" can provide "python-api-*".
Neil
Jim Penny wrote:
> Why? Could you better explain your reasoning here?
> On the face of it, it certainly seems that python-1.5 ought to be
> able to provide python-api-1.5.
It breaks dependencies. We've been through this before but I'll explain
it again. Here's a dependency graph:
Donovan Baarda wrote:
> In my above diagrams the (>=2.1,<2.2) dependancy could be replaced with a
> python-api-2.1 provided by python (as suggested by Neil), but I think this
> actually introduces confusion rather than convenience. The problem is that it
> doesn't really represent a particular v
Anthony Towns wrote:
> Hrm. That doesn't seem to make sense. For example, Python 2.1 supports
> the Python 2.0 API completely, and Python 2.2 supports the Python 2.1
> API completely too, doesn't it?
API in this context means binary API. Only Python 2.1.X supports the
2.1 API.
The point is proba
Anthony Towns wrote:
> Which scheme was that?
Quickly:
python-2.1_2.1.1
python_2.1.1 (depends on python-2.1) (does "ln /usr/bin/python{2.1,}")
python-2.1-_ (depends on python-2.1)
python-_ (depends on python and python-2.1-)
_ (depends on python and python-,
#!/u
Matthias Klose wrote:
> At any given time, the package `python-base' should represent the
> current stable upstream version of Python. XXX: Should we have an
> exception for the case, when a new upstream version is released during
> a Debian freeze?
It should probably be rewor
Anthony Towns wrote:
> On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > Say, you would install 2.1.2 in /usr/local.
>
> How about we just say "Don't install other versions of python in
> /usr/local" ?
Please no. Making this work properly is not hard. Besides, if the
magic i
Matthias Klose wrote:
> - Recommend /usr/bin/env python over /usr/bin/python
Again I must express my opposition to this idea. Using /usr/bin/env
totally breaks dependencies. There's no way that I'm going to let
Debian policy dictate what I can have in my path.
Neil
Anthony Towns wrote:
> On Mon, Oct 22, 2001 at 08:32:33AM -0700, Neil Schemenauer wrote:
> > Anthony Towns wrote:
> > > On Mon, Oct 22, 2001 at 10:13:17AM +0200, Gregor Hoffleit wrote:
> > > > Say, you would install 2.1.2 in /usr/local.
> > > How about we ju
Junichi Uekawa wrote:
> I have been looking at python 2.1, and python2.1 debian/copyright file tells
> me that it is "not GPL compatible".
>
> Is it still so?
No. Python 2.1 is derived from 1.6.1 and _is_ GPL compatible.
According to some laywers Python 2.0 is not GPL. According to other
laywer
dman wrote:
> As I understand/recall the history, python 2.0 and 2.1 are not "GPL
> compatible". However, 2.0.1 and 2.1.1 (note the micro version
> increase) are "GPL Compatible".
It's probably better to check if you're unsure rather than speculate or
guess. From the 2.1.1 LICENCE file:
Pyt
Joe Reinhardt wrote:
> -python setup.py bdist
> cd debian/scipy && tar zxvf ../../dist/SciPy-0.2.0.linux-*.tar.gz
The install command takes a --prefix argument. That might be cleaner
than using bdist.
Neil
Gregor Hoffleit wrote:
> IMHO this is the point where we should make a big step, and enforce a quick
> transition of the archive to Python 2.0.1.
Yes please. Packages named python suck. I'm willing to work on
rebuilding packages or whatever else needs to be done.
Neil
Gregor Hoffleit wrote:
> Until now I had the impression that in general it's not necessary to
> have more than one Python version on your machine at the same time
> (except perhaps you're a Python core developer). Feedback from
> python-dev though was that it's definitely necessary to allow and
> s
dman wrote:
> No. The bytecodes change when the developers feel like it (more or
> less). That interface is not constant between even "minor" version
> changes.
Not quite true. Bytecode stays compatible between micro (i.e. bugfix)
releases.
Neil
Matthias Klose wrote:
> Moshe Zadka writes:
> > I was wondering if you mind passing Python 1.5 maintainership to me.
>
> I do not mind passing the maintainership, but I do mind keeping it in
> unstable.
I don't think it is up to individual Debian developers to decide what
packages should be allow
Martin Schulze wrote:
> Ouch. It's very sad that upstream says that they don't have the resources
> to fix security bugs in a widely used software.
AFAIK, rexec and Bastion are not widely used.
Neil
65 matches
Mail list logo
