Re: Bug#382252: Python PATH problem
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 also in charge of removing them. > > Too bad upstream Python seems to have rejected or abandoned the PEP to > make this happen. I don't think the idea itself has been rejected. If someone would step up and continue the PEP or write a new one, I'm pretty sure it would be accepted. Neil -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposal: Reorganizing Python for Python 2.0
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 along side of the regular Debian Python package. No problem. Neil
Re: Proposal: Reorganizing Python for Python 2.0
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 are: http://people.debian.org/~nas/ The packages are a little rough but they work for me. YMMV. Neil
Re: Python license and GPL programs
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 problem if you link with the Python interpreter. Curiously, Debian and RMS happen to believe that dynamic linking is the same as static linking in this regard (I disagree). You can overcome this problem by adding something to your license saying that it is okay to distribute it linked to Python. Python code executed by the interpreter can be licensed however you like. You could also forget about silly license issues like this. Its a technicality. The only people that really care are lawyers (although they might try to make your life miserable while making some money for themselves). I have it on good authority (ie. Guido) that the incompatibility between the CNRI Python license and the GPL is going to be fixed soon. Neil
Re: Python license and GPL programs
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 with our lives. > Finally, you can stick with Python 1.5.2; I also believe there > were rumours about a FSF-encouraged fork of Python 1.5.2 to > re-implement all of the features found in Python 2. I have no > idea how feasible or likely that is. That would be madness. Neil
[EMAIL PROTECTED]: Our application doesn't work with Debian packaged Python]
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 message was on the debian-python list. Does anyone know why > the patch is needed? > - handle = dlopen(pathname, RTLD_LAZY); > + handle = dlopen(pathname, RTLD_LAZY | RTLD_GLOBAL); This comes back every once in a while. It means that they have an module whose shared library implementation exports symbols that are needed by another shared library (probably another module). IMO this approach is evil, because RTLD_GLOBAL means that *all* external symbols defined by any module are exported to all other shared libraries, and this will cause conflicts if the same symbol is exported by two different modules -- which can happen quite easily. (I don't know what happens on conflicts -- maybe you get an error, maybe it links to the wrong symbol.) The proper solution would be to put the needed entry points beside the init entry point in a separate shared library. But that's often not how quick-and-dirty extension modules are designed... --Guido van Rossum (home page: http://www.python.org/~guido/) - End forwarded message -
Re: Please wait before bloating Debian with python2- packages
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
Re: Dependencies on Python
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
Re: Dependencies on Python
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 builds OK with both these lines left commented out. > The install fails later but I'll have another look at that now > that I'm not goofy from no sleep. You haven't given me much detail to go on there. Hopefully you can sort it out after some rest. Neil
Re: RFC: python-base, debconf and py/pyc files
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 files > * install only .py files You forgot about .pyo files. I don't think this is worth doing. If you care about space it would be better to look through the library and remove what you don't need. Perhaps the trimming process would include: find /usr/lib/python2.1 -name '*.py' | xargs rm The .py files comprise 13% of the space used by a Python 2.1b2 install. I don't think the savings are worth the cost (poor tracebacks, more for work Gregor). Neil
Re: Python 2.1 out
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. > > Actually, it'd be nice just to have Python 2.1 in woody before the > freeze, whether or not it's GPL compatible. Or even get more Python > 1.5 packages built for Python 2.0 as well. Guido has recently checked in a license change that makes Python GPL compatible. That was confirmed by RMS and his laywer. This change will go into the 2.0.1 and 2.1.1 maintenance releases as well as 2.2. I'm not sure if 2.0.1 will be out before the freeze. Moshe should know. I think he's on this list. Neil
Re: python-2.1 for unstable?
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 want multiple versions of Python installed they can easily download the source and install them into /usr/local/bin. Neil
Re: python-2.1 for unstable?
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
fine when installed in /usr/local.
> If you do not modify the code, all of your installed python
> modules/packages (in prefix=/usr) will not be found by
> /usr/local/bin/python.
Which modules are you talking about? If you have pure Python
modules you can make them available to Python 2.1 by copying the
source files to /usr/local/lib/python2.1/site-packages and
running compileall.py on them. Extension modules have to be
recomplied for 2.1. Its easy if the extensions use distutils:
$ python2.1 setup.py build
$ su
$ python2.1 setup.py install
> I don't think I ever got it quite right, perhaps a simple
> export PYTHONPATH=/usr/local/lib/python{2,2.1}:/usr/lib/python1.5
Bad idea. The stuff in /usr/lib/python1.5 is for Python 1.5. It
might by chance work with 2.0 or 2.1 but don't count on it.
Neil
Re: Status report on python2 transition
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 compileall import main;main()' -q $DIR which fails if a stock distribution of compileall is used (it doesn't support -q). I've seen other packages do this as well. > That's our current setup (well-behaved packages should have a dependency > on "python-base >= 1.5, python-base << 1.6"). Look at the mess we're now > running into, now that we want to upgrade this to Python 2.1.1. All > packages have to be recompiled at once. What's a "well-behaved package"? Extension modules depend on the version of Python that they were compiled against. If you upgrade the interpreter you must upgrade the extensions. How are you planning on avoiding this? Neil
Re: Status report on python2 transition
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 upgrade python-base to 2.1.1. All packages that contain third party extension modules, such as python-mxdatetime, will need to be recompiled for 2.1.1. What I don't understand is what problems a versioned python-base package will solve. I don't think its going the meet the needs of hardcore Python developers. For those people compiling the source is not a big deal. I think its going to confuse the average Debian user. All the Debian Perl packages sure confuse me. I think its also going to cause more work for the Debian maintainers. Neil
Re: Status report on python2 transition
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 code broke after an upgrade. > Possible solutions for cross-version compatible code would be > installation in a version-neutral directory (e.g. > /usr/lib/python/site-packages) and either adding this to sys.path (has > been depreciated in python-dev) or somehow arranging symlinks into the > actual versioned site-package directories. I assume we are talking about cross-version compatible _library_ code now (ie. libraries implemented in Python). In that case, something like /usr/lib/python/site-packages sounds like a reasonable solution to me. Note that Python is smart enough to check the version numbers of bytecompiled code. For example if foo.py and foo.pyc both exist but the .pyc file is an old version then the .py file is used. This slows down the import a bit but causes no other ill effects. I think it may be enough to have Python library code install itself in /usr/lib/python/site-packages and be compiled by the currently installed version of Python. If python-base is upgraded then its postinst recompiles all of the code in site-packages. Could it be that simple? Maybe I've missed something. Neil
Re: Status report on python2 transition
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 distribute then the env trick is a good idea since you don't know were Python is installed. For Python programs/scripts that come with Debian we know that Python is /usr/bin/python. Neil
Re: Question for the transition
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
Re: Question for the transition
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: > For what it's worth, Zope is not compatible with python 2.x, ... AFAIK, Zope 2.4.0 and later is compatible with Python 2.1. I still don't see the need for multiple versions of Python packages. Neil
Re: Question for the transition
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
Re: Question for the transition
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 python packages that provide binary modules > should be check, I think there have been significant changes with C > interfaces. Okay, I've got python-2.1.1 packages. I'm working on python1.5-1.5.2 packages (not python1-1.5.2, the Python binary API changes with major and minor versions but not micro). If Zope is the only thing that needs 1.5.2 then I will try to make zope2.3-x packages. How much should I split up the python1.5.2 source package? I'm included to have just one python1.5.2 binary package. Thoughts? Neil
Experimental Python packages
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-regrtest python-tk python-xmlbase idle-python python1.5 python1.5-dev zope2.3.3 The zope package depends on python1.5. The dependencies, conficts, replaces, provides fields need to be adjusted yet. There are still a few lintian warnings to be cleaned up yet as well. Also, I'm planning to build new versions of all the packages that don't work with Python 2.1.1 (probably they include extension modules but don't depend on the major and minor version of Python). Before I spend too much time on this, is there a problem with this approach? It seems to be much simpler than using versioned packages for everything Python related. I'm especially interested in Gregor's opinion since he maintains a lot of these packages. Neil
Re: My proposal about sys.path
Jérôme Marant wrote: > Would you please comment on this? Looks reasonable to me. Neil
Re: Question for the transition
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 > to do it themselves. I'm not saying Debian shouldn't support multiple installed versions of Python. I'm saying that the current stable version of Python should be in the package "python" or "python-base". Most packages would depend on "python". Old or experimental versions of Python should be called "python-.". Neil
Re: Experimental Python packages
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 information. I've made some progress in this area. I'll try to upload new packages today. > Some things I've noticed to start with: > > - Lots of references to Python 1.5 or 2.0. > > - python2.1-base tries to install an alternative for /usr/bin/python >in its postinst, so it has to conflict with old versions of >python-base that contain this. There is no python2.1-base package. The package is python-base_2.1.1. > - The shlibs file refers to "python2-base (>= 2.1-1)" but the package >is python2.1-base. It should be "python-base (>= 2.1.1-0)". > - /usr/bin/pydoc isn't versioned, so python2.2-base will have to >conflict with this version of python2.1-base. It should probably >be /usr/bin/pydoc2.1 with a "pydoc" alternative, and start with >#!/usr/bin/python2.x as appropriate, for future versions. 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. > I'd also like to know: > > - What dependencies should packaged modules declare: > a) when the maintainer only plans on supported whatever the > latest version of Python is? I think it should depend on "python". If the package includes extension modules then it needs to depend on the major and minor version of Python (I think "python (= X.Y)" works, someone please correct me if that's wrong). > b) if there'll be one package per Python version? > > - What should packages that use Python depend on? Presumably >"python" if the maintainer feels optimistic, otherwise >python2.1-base. See above. Neil
Re: Experimental Python packages
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 fixes to them so you might want to do a diff between them an your packages. You'll have to ignore all the s/python2/python/ changes. Neil
[EMAIL PROTECTED]: Re: [Python-Dev] re-ordering sys.path]
The word from the man himself. :-) I'm make this change in my experimental python_2.1.1 packages. Neil - Forwarded message from Guido van Rossum <[EMAIL PROTECTED]> - Date: Thu, 06 Sep 2001 14:27:19 -0400 From: Guido van Rossum <[EMAIL PROTECTED]> Subject: Re: [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?) > Will this work? If so, why is it not already done? I think it will work just fine. I suppose I was afraid that people would abuse this to override standard modules that will break other stuff in subtle ways, but they can do that anyway using the $PYTHONPATH environment variable. --Guido van Rossum (home page: http://www.python.org/~guido/) - End forwarded message -
Re: Experimental Python packages
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 which Python /usr/bin/python is. Please think a little. pydoc is in the same package as python-base. Neil
Re: Experimental Python packages
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 > reasons why an admin would want a certain implementation to be the > default. These reasons could include > o understanding a certain version & knowing it works (before > upgrading and finding unexpected breakage) > > o Jython or Stackless Why can't the system admin use /usr/local/bin/python? Using alternatives for /usr/bin/python is a stupid idea. I quote Joey Hess: The problem is, if you have two versions of perl (or python) installed and /usr/bin/perl(python) is managed with alternatives, dependancies are useless. A package that uses perl 5.6 (ptyhon 2.0) features should depend on that package. But a user can install an older version still, and can modifiy the alternatives to make it the default, and then the program breaks, even though its alternatives are satisfied. The only way to make a program that uses perl 5.6 (I'll stop putting the equivilant ptyhon stuff in parens now :-) reliably work is to make it use #!/usr/bin/perl-5.6. But this is just shooting yourself in the foot when perl 5.7 comes out and your package works with it fine except it refuses to use it because the filename is different. It's a horrific can of worms, which is why perl in debian is no longer going to do this at all -- it's just not worth it. I encourage you python folks to think this through before adopting a similar scheme. Good luck! I think Python and Perl are similar enough that this advice applies. Also, I respect the Perl packagers enough to heed their advice. Neil
Updated experimental packages
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 updated my set of experimental packages. They are available at: http://people.debian.org/~nas/woody/ There are three source packages: python_2.2.1 python-1.5_1.5.1 zope-2.3_2.3.3 These create the following binary packages: python_2.1.1 python-dev_2.1.1 python-elisp_2.1.1 python-examples_2.1.1 python-gdbm_2.1.1 python-mpz_2.1.1 python-regrtest_2.1.1 python-tk_2.1.1 python-xmlbase_2.1.1 idle-python_2.1.1 python-1.5-dev_1.5.2 python-1.5_1.5.2 zope-2.3_2.3.3 The zope-2.3 package depends on python-1.5. The python-base package is gone. I've changed sys.path to: ['', '/usr/local/lib/site-python', '/usr/local/lib/python2.1/site-packages', '/usr/lib/python2.1/site-packages', '/usr/lib/python2.1', '/usr/lib/python2.1/plat-linux2', '/usr/lib/python2.1/lib-tk', '/usr/lib/python2.1/lib-dynload'] as per Jérôme Marant's request. I think the only major problem left to solve is fixing packages with broken dependencies. Using Gregor's terminology I think that the policy should be: Python modules and Python embeding apps should depend on "python (>=X.Y), python (<=X.Y)". They should not install any modules in the standard Python path. I'm willing to build new version of packages with broken dependencies. Can we handle the upgrade from Python by having a long list of conflicts in the "python" package? Something like: Conflicts: python-some-extension (<< X.Y), ... Please advise. I'm very determined to get Python 2.1.1 into woody and am willing to put in a lot of work to make it happen. Neil
Re: Experimental Python packages
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 specific customizations. Don't screw with /usr/bin/python. > Why should Debian decide that bin/python _must_be_ a specific version > of Python when it is so simple to specify which python a executable > needs. "Gratuitous" is the only word I can think of that accurately > describes behaviour like that. What's wrong with /usr/local/bin/python? > Pydoc is part of Python, so there should be no problem explicitly > specifying which Python that is (it is not limiting in any way). > > The experimental py-2.1 packages have: > > 1)#/usr/bin/env python2 > > it should be: > > 2)#/usr/bin/env python2.1 No, it should be: #!/usr/bin/python2.1 You can't use /usr/bin/env. What happens if someone installs python2.1 somewhere else in the path and that version does not have the modules that the script needs? You should use "#!/usr/bin/env python" for scripts that you write or locally install scripts. That way you can change /usr/local/bin/python to point to a newer version of Python and everything starts using that new version. > you (Neil) want: > > 3)#/usr/bin/python > > I like 2) because it lets me have a /usr/local/bin/python2.1 > overshadow the packaged 2.1 if I want, simply by fiddling with > symlinks in /usr/local/bin. If every executable did that I could > point python to whatever I wanted and things just work. Things would not work. Things would break. How do we assure that the locally installed Python is compatible with all the installed Python packages? > ...where has my thinking failed? For some reason you insist on being able to change /usr/bin/python. If you give up on that everything is simple and works fine. Neil
Re: [Python-Dev] Status of Python in the Red Hat 7.1 beta
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 team. I'm not sure what you mean by "should just work". Source compatibility between 1.5.2 and 2.0 is very high. The 2.0 NEWS file should list all the changes (single argument append and socket addresses are the big ones). The two versions are _not_ binary compatible. Python bytecode and extension modules have to be recompiled. I don't know if this is a problem for the Red Hat 7.1 release. Neil
Re: Updated experimental packages
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
Debian Python Policy [draft]
Please comment.
Neil
Debian Python Policy
Neil Schemenauer <[EMAIL PROTECTED]>
version 0.1
---
Abstract
This document describes the packaging of Python within the Debian
GNU/Linux distribution and the policy requirements for packaged Python
programs and modules.
Copyright Notice
Copyright (C) 2001 Software in the Public Interest
This manual is free software; you can redistribute it and/or modify it
under the terms of the GNU General Public License as published by the
Free Software Foundation; either version 2 of the License, or (at your
option) any later version.
This is distributed in the hope that it will be useful, but WITHOUT
ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
for more details.
A copy of the GNU General Public License is available as
`/usr/share/common-licences/GPL' in the Debian GNU/Linux distribution
or on the World Wide Web at The GNU Public Licence
(http://www.gnu.org/copyleft/gpl.html).
You can also obtain it by writing to the Free Software Foundation,
Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
---
Contents
1.Python Packaging
1.1. Stable and Legacy Versions
1.2. Module Path
2.Packaged Modules
2.1. Dependencies
2.2. Installation
2.3. Module Package Names
3.Python Programs
3.1. Version Independent Programs
3.2. Version Dependent Programs
4.Programs Embedding Python
4.1. Building Embedded Programs
4.2. Embedded Python Dependencies
---
1. Python Packaging
---
1.1. Stable and Legacy Versions
---
At any given time, the package `python' should represent the current
stable upstream version of Python.
Only one package may contain the `/usr/bin/python' binary and that
package must either be `python' or a dependency of that package.
The `python' package must provide `python-.'; where and
represent the major and minor versions of the Python, respectively.
There can be any number of legacy Python packages available. These
must be named `python-.' and include the file
`/usr/bin/python.'.
1.2. Module Path
Python searches a number of directories for modules. The module
search path for Debian has been ordered to include these locations at
the beginning of the path in the following order:
/usr/local/lib/site-python
/usr/local/lib/python./site-packages
/usr/lib/python./site-packages
---
2. Packaged Modules
---
2.1. Dependencies
-
Packaged modules must depend on `python-.'.
2.2. Installation
-
Packaged modules must install into `/usr/lib/pythonX.Y/site-packages'.
After installation, Python source files must be compiled. This should
be done with a `postint' script similar to the following example:
#! /bin/sh -e
PACKAGE=python-extension
VERSION=.
LIB="/usr/lib/python$VERSION"
DIRLIST="$LIB/site-packages/extension"
case "$1" in
configure|abort-upgrade|abort-remove|abort-deconfigure)
for i in $DIRLIST ; do
/usr/bin/python$VERSION -O $LIB/compileall.py -q $i
/usr/bin/python$VERSION $LIB/compileall.py -q $i
done
;;
*)
echo "postinst called with unknown argument \`$1'" >&2
exit 1
;;
esac
Before removal of the package, the compiled files must be removed.
This can be done with a `prerm' script similar to the following
example:
#! /bin/sh -e
PACKAGE=python-extension
dpkg --listfiles $PACKAGE |
awk '$0~/\.py$/ {print $0"c\n" $0"o"}' |
xargs rm -f >&2
2.3. Module Package Names
-
Python module packages should be named for the primary module
provided. The naming convention for mo
Re: Debian Python Policy [draft]
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
Re: Debian Python Policy [draft]
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 happened to /usr/lib/site-python? Its been deprecated by the upstream distribution of Python. What would it be used for? Packaged modules must install themselves into /usr/lib/pythonX.Y/site-packages. Neil
Re: Debian Python Policy [draft]
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 #!/usr/bin/python1.5 > > > 1.2. Module Path > > > > > > Python searches a number of directories for modules. The module > > search path for Debian has been ordered to include these locations at > > the beginning of the path in the following order: > > > > /usr/local/lib/site-python > > /usr/local/lib/python./site-packages > > /usr/lib/python./site-packages > > The debian search path for poo is (possibly in some other order, per > later messages): > > /usr/local/lib/site-python > /usr/local/lib/python2.1/site-packages > /usr/lib/python2.1/site-packages > ... > > and the debian search path for bah is: > > /usr/local/lib/site-python > /usr/local/lib/python1.5/site-packages > /usr/lib/python1.5/site-packages > ... > > ? > > (that is, even in the 'python' package, versioned paths are used.) That's right. > > 4.1. Building Embedded Programs > > --- > > > > Programs which embed a Python interpreter must declare a > > `Build-Depends' on `python-dev'. > > > > Versioning? If a package requires the dev for python1.5, will we > be providing a python1.5-dev? Yes, I'll add that to the document. In general though packages should try to use the latest version of Python. Versioned packages (as in the version in the name) cause lots of pain and we should try to keep them to a minimum. > Finally, what about package naming. Suppose I were maintaining > python-popyda (which I happen to be). Suppose python (2.1) is released > and it turns out that python-popyda is incompatible with it (I am not > saying it is, I just want a concrete hypothetical). Should > python-popyda be renamed to python1.5-popyda as soon as possible? I don't think so. If there is only one popyda package then it should be called "python-popyda". It should depend on python-X.Y. Hopefully X.Y is the latest stable Python release. > Or should it remain as python-popy with a conflicts that prevents > it from being used with python (2.1)? Conflicts should not be necessary. > Suppose a later version comes out which is 2.1 available, but for > some transition period, I want to provide both a 1.5 and a 2.1 > compatible version. Should package names be python1.5-popyda and > python-popyda? In that case you should provide a python-1.5-popyda package. I'm hoping we can avoid doing that for most packages but the mechanism is there if we need it. > Again, I have some reservations about breakage on a mass scale > when a new major of python comes out with this scheme, but I guess > paranoid maintainers can take care of that by routinely making an > equality depends in our packages. The breakage should only happen once or twice in the Debian development cycle (i.e. when a new version of Python gets uploaded). Since extension modules depend on the major and minor version of Python that they are compiled against I see no way of eliminating the problem. When a new version of Python gets uploaded, a legacy version should probably get uploaded as well. For example, if the current "python" is 2.0 and the new "python" is 2.1 then "python-2.0" could be provided to ease the transition. The "python-2.0" package could be removed if there was no "python" version 2.0 in an official Debian release. Neil
Re: I'm trying experimental packages for 2.1
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
Re: Debian Python Policy [draft]
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 recompiled for it. The spam > maintainer is on holiday, so it doesn't get recompiled for a while. > If I then install "lumberjack", which depends on python-2.2 and on > eggs, apt will upgrade python and eggs to satisfy the dependencies, > and hopefully install "python-2.1" to keep spam happy. > > Still with me? All the dependencies are satisfied, but spam doesn't > work any more - the eggs module has disappeared out from under it. Excellent point. I've updated the policy document to prevent this. The python package should provide python-api-X.Y. Module packages should depend on python-api-X.Y. If someone packages an older version of Python they should call it python-X.Y. Packaged modules for that Python should depend on python-X.Y. Older versions of Python should never provide python-api-X.Y. Neil
Re: Debian Python policy.
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. > 3) multiple alternatives versions of Python installed at a time. I am aiming for option 3. There would be one official "python" package. Most packaged modules depend on that package. If people want to package older versions of Python they may do so. Those packages are independent of the "python" package. > Option 1 means every time Python upgrades, all packages dependant on > that version of Python are broken and have to be upgraded, with old > versions removed from the distro. 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 that. > Your policy seems to be aiming for Option 3... the hardest, but is > that really what we want? Using alternatives for Python is not a good idea, IMHO. The Perl packagers tried this and it was a nightmare. Neil
[Draft] Debian Python Policy 0.2
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 of my head):
- Re-order sys.path (not done in the python package yet).
- Packaged modules should depend on python-api-X.Y
- Remove section on legacy versions of Python (they are
independent). I should probably add a section saying that
packages other than "python" cannot provide python-api-*.
- Simplify postinst and prerm scripts by including
/usr/lib/package-{install,remove} in the python package. This
mechanism could probably eventually be used to share packages
between different versions of Python but let's not do that yet.
Please comment. Thanks.
Neil
Re: I'm trying experimental packages for 2.1
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 (>= 2.1), python (< 2.2)". That's it. Neil
Re: I'm trying experimental packages for 2.1
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 the need for "api" there ... It allows people to package older versions of Python as python-X.Y. Neil
Re: Debian Python policy.
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 > > that. > > Yes, but the old packages still work for the old version of Python. One of > the main reasons to continue running old versions of Python is because other > packages haven't been updated yet. Try to think exactly how this would work. On the surface is seems like a good idea but I think it leads to a lot of complexity and more work in the end for the maintainers. Say I have a Python program "foo" that requires "python-bar". Let's say the installed version of Python is 2.0. So "python-bar" installs its modules into /usr/lib/python2.0. "foo" depends on "python-bar" and uses /usr/bin/python. What happens when /usr/bin/python becomes Python 2.1? Oops, it doesn't have the "python-bar" modules. Okay, how about we make "foo" use /usr/bin/python2.0. Now we upgrade to Python 2.1 and every works fine. Now we upgrade "python-bar" so that it installs in /usr/lib/python2.1. Oops, "foo" is broken again. I think it only solution is to have the version in the package name for all Python packages. Now instead of updating all the modules when a new version of Python is installed you have to update all the modules and the the programs that use Python as well. You've added a large amount of complexity to handle some easily repaired breakage that happens to the unstable version of Debian about once per year. I don't think that's a good tradeoff. Neil
Re: [Draft] Debian Python Policy 0.2
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 must be updated when a new version of Python is installed. Neil
Re: Debian Python policy.
[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 and a large > python-X.Y-foo added, where python-X.Y-foo is mostly the same as the > old python-foo. By the time Python X.Y+1 comes out there is probably a micro release of X.Y available. > That is, if you actualy intend to produce python-X.Y packages... I > suspect you wouldn't bother with your scheme. Only if absolutely necessary. Does Potato need Python 1.6 or 2.0? I suspect not. I'm not sure it even needs 1.5.2. > Something that does complicate it all is even python modules that are version- > independant become tied to a particular version when they are installed > into /usr/lib/python-X.Y (as in your python-bar above). That's not as bad as progams becoming version dependent (as happens in your proposal). So far I have about 70 modules on my list that need to be updated when python is updated. There are over 100 packaged programs that use python. From my initial investigation it looks like most of them will work fine if python becomes version 2.1.1. > 3) have python-foo which depends on python (>=X.Y) install into > /usr/lib/python, and install links in /usr/lib/pythonA.B/ to > /usr/lib/python/* for all A.B >= X.Y. Note that these links will need > to be updated every time a new python-X.Y or python-foo is installed. > Perhaps a utility "update-links" function in the python (X.Y) package > should be provided to do this. > > Note that 1) and 2) will break if a python upgrade changes the python > byte- code. Only 3) is bytecode-change-resistant. That won't work for extension modules. Also, bytecode is only compatible between micro releases. Neil
Re: Debian Python Policy [draft]
Carey Evans wrote: >/> python-2.1 -\ >spam -- > python >\---> python-eggs ---> python-api-2.1 ---/ spam should depend on python not python-2.1. Neil
Re: Debian Python policy.
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 packages. I known this can be made to work. I think it's ugly and not worth the effort however. Perhaps we need to have a vote. Neil
Re: Debian Python Policy [draft]
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
Re: Debian Python Policy [draft]
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: /\ spam -- > python (2.1) \---> python-eggs ---> python-api-2.1 ---/ The spam program is portable between Python versions. Now, if we upgrade python to 2.2 and have a python-2.1 package that provides python-api-2.1 we have the following broken dependency graph: /---> python (2.2) spam -- \---> python-eggs ---> python-api-2.1 ---> python-2.1 We can try to fix this by putting the version in the module package names as well (this is what Donovan and other people have been suggesting). First we have: /-> python ---\ spam -- > python-2.1 \---> python-eggs ---> python-eggs-2.1 ---/ The python is a small package to create a link from /usr/bin/python2.2 to /usr/bin/python. python-eggs is a dummy package for dependencies (similar to what is done for GCC). When we upgrade Python to 2.2 we have: /-> python ---> python-2.2 spam -- \---> python-eggs ---> python-eggs-2.1 ---> python-2.1 The dependencies are still broken. We could have: /\ spam -- > python-2.1 \> python-eggs-2.1 --/ That makes spam dependent on the version of Python installed. Perhaps I'm missing some detail of Donovan's plan. Neil
Re: Debian Python Policy [draft]
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 version of the api, just a particular > version range of the "latest" python package. It does represent the version of the API (for bytecode and the extension module binary interface). I suppose I am abusing it in the sense that only the "python" can provide it. If we go with your plan we drop -api bit and use python-X.Y instead. Neil
Re: [Draft] Debian Python Policy 0.2
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 probably moot anyhow since I've almost finished creating packages using the scheme proposed by Donavon and others. I need to update the policy and doing some more testing yet though. Neil
Re: [Draft] Debian Python Policy 0.2
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-,
#!/usr/bin/python)
-2.1_ (depends on python-2.1 and
python-2.1-, #!/usr/bin/python2.1)
Until we get packages with broken dependencies fixed we could have:
python_1.5.2 (depends on python-1.5)
Note that this scheme would not alternatives to manage /usr/bin/python.
That link is controlled by the python package. This scheme is quite a
bit more complicated than what I proposed in the 0.2 policy draft. Oh
well.
I'm on vacation until Oct. 17 but I should have experimental packages
ready soon after that, they are almost done already. I don't know
what's happening with Woody. Can anyone explain it to me? Gregor seems
to be busy with other things right now.
Neil
Re: Debian Python policy & Upgrade Path (draft/proposal)
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 reworded so that it means the latest version we are able to get into the release. > Only one package may contain the `/usr/bin/python' binary and that > package must either be `python' or a dependency of that package. If you call the main package "python-base" then there is no "python" package. > There can be any number of legacy Python packages available. These > must be named `python-.' and include the file > `/usr/bin/python.'. Here you have "python-." and elsewhere you have "python.". > 1.2. Base Package > - > > In order to provide a minimal installation of Python for use by > applications without requiring the whole of Perl to be installed, the > `python-base' package contains the binary and a basic set of modules. Perl? Why the -base? There is not a stripped down version of Python and a full version. Calling the package "python" is clearer, IMHO. > Python searches three different locations for modules. The module > search path for Debian has been ordered to include these locations at > the beginning of the path in the following order: > > /usr/local/lib/site-python > /usr/local/lib/python./site-packages > /usr/lib/python./site-packages That should be: /usr/local/lib/python./site-packages /usr/local/lib/site-python /usr/lib/python./site-packages > 3. Support all/most versions of python, including the default. > Works only for architecture independant python modules. NOT YET > SUPPORTED!!! I assume you are refering to scheme where modules would get installed into the search path of multiple Python interpreters. I'm not sure that's a good idea. > 2. You have version independant Python scripts/programs. Create a > single package that depends on `python-base'. Any name can be > used, but `python-' is recommended for a library. It > should install modules somewhere inside `/usr/lib/python/' and > use `#!/usr/bin/python' for programs. The `postinst' script > should create symlinks in all `/usr/lib/pythonX.Y/' directories > that point to its `/usr/lib/python/' files and compile them. If we going to do this, it's stupid for each package's pre/post scripts to do the work. I had implemented scripts so that packages could do: #!/bin/sh # postinst script PACKAGE=`basename $0 .postinst` /usr/lib/python/install-package $PACKAGE #!/bin/sh # prerm script PACKAGE=`basename $0 .prerm` /usr/lib/python/remove-package $PACKAGE Much cleaner and harder to screw up, IMO. > 4.1. Building Embedded Programs > --- > > Programs which embed a Python interpreter must declare a > `Build-Depends' on `python.-dev'. Extension modules should do this as well. > A. Upgrade Procedure > > > This section describe the procedure for the upgrade from the current > `python- (1.5)' packages to the `python1.5-' packages, the > removal of the `python2-' packages and the upgrade to the recent > `python2.1-' upstream packages: > > 1. File bugs against any packages that do not meet the above > alternatives for packages. I have almost all the packages fixed already (for my proposed policy, but it would be easy to change for your proposed policy). I was going to email the maintainers diffs. I'm about ready to give up trying to improve the Debian/Python situation. I assumed the Python maintainers were busy and that's why they didn't respond to any of my posts. Now, new packages have been installed into woody. Hmm. Neil
Re: What should we do now?
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 is "#!/usr/bin/env python" then we would have to say "don't install other versions of python in your path". Neil
Re: Debian Python policy & Upgrade Path (draft/proposal) [0.3.3]
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
Re: What should we do now?
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 just say "Don't install other versions of python in > > > /usr/local" ? > > Please no. Making this work properly is not hard. > > Again, _why_ does this matter? Who does this? Is it even remotely common? Every Python developer I know does it. > That people would even consider installing another version of python in > /usr/local surely just points to a problem with the Debian packaging, no? The python in my path is on an NFS server. It includes many extensions that are not packaged by Debian. When we upgrade we don't want to upgrade each box individually. Also, since we are using version 2.1.1, yes, it's also a problem with Debian packaging. The Debian release cycle is too long to track stable Python releases. > The problems with using "#!/usr/bin/python1.5" is threefold: first, it > makes dependencies that much more complicated: *all* python scripts have > to depend on versioned modules in every way This has nothing to do with using "/usr/bin/python(X.Y)?" vs. "/usr/bin/env python(X.Y)?". If you want to use the latest packaged version of Python you should use "/usr/bin/python" > If you install new versions of standard tools in /usr/local you have > to be careful. This applies to a hypothetical /usr/local/bin/dpkg, or > a /usr/local/bin/sed, or whatever. Going out of your way to make sure > it doesn't apply to a /usr/local/bin/python seems to this observer a > complete waste of time. The effort involved is small. Use "/usr/bin/python" instead of "/usr/bin/env python". Use "/usr/bin/pythonX.Y" instead of "/usr/bin/env pythonX.Y". Neil
Re: Python-2.1 becoming Debian's default Python version
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 laywers it is. Neil
Re: Python-2.1 becoming Debian's default Python version
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: Python 1.6.1 is essentially the same as Python 1.6, with a few minor bug fixes, and with a different license that enables later versions to be GPL-compatible. Python 2.1 is a derivative work of Python 1.6.1, as well as of Python 2.0. Cheers, Neil
Re: using setup.py in debian/rules
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
Re: Python 2.0.1; transition plans for woody
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
Re: Status report on python2 transition
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 > support multiple concurrent versions of Python even on production > machines. This doesn't imply that Debian has to support multiple concurrent versions of Python _packages_. To me, it means Debian should play nicely if you want to install other versions of Python in /usr/local or wherever. Currently it does not. > For one, I've changed my mind and accepted that there's a need to > support multiple concurrent Python versions in Debian. Woody should have one core Python package (python-base_2.1.1-X). Extension modules should have a versioned dependency on the interpreter (ie. "python (= X.Y)"). Pure Python packages should only have a dependency on "python" or perhaps "python (>= X.Y)". Neil
Re: Python versions and bytecode
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
Re: Maintaining Python 1.5
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 allowed in Debian. Neil
Re: Python rexec and Bastion flaws
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
