On Sun, Feb 10, 2002 at 10:26:26AM +0100, Matthias Klose wrote:
Donovan Baarda writes:
G'day,
just thought I'd have another look at the current policy and I couldn't find
it. Where is it again?
/usr/share/doc/python, anybody actually reading the docs?
Ahh, it's included in the python
G'day,
just thought I'd have another look at the current policy and I couldn't find
it. Where is it again?
Can we get a link to it put on the Debian devel page?
http://www.debian.org/devel/
--
--
ABO: finger [EMAIL
Hello Pythoneers,
another version of the dh_purepython script is online at
http://people.debian.org/~calvin/purepython/.
It provides support for Section 2.2.3 of the Python Policy
which adresses version-independent Python modules.
I would be pleased to hear any comments and/or suggestions from
On Sun, Jan 13, 2002 at 03:48:40PM +0100, Bastian Kleineidam wrote:
A pythonX.Y package must have
1) a postinst script to byte-compile all previously installed
packages who use dh_purepython
2) a prerm script to remove byte-compiled files from all previously
installed packages who
Torsten Landschoff writes:
On Sun, Jan 13, 2002 at 03:48:40PM +0100, Bastian Kleineidam wrote:
I have untested scripts python.postinst and python.prerm for this.
If you ask me, scripts for that should go into the python package so
that not every python-xxx package has to carry them itself.
On Sun, Jan 13, 2002 at 09:32:58PM +0100, Matthias Klose wrote:
If you ask me, scripts for that should go into the python package so
that not every python-xxx package has to carry them itself. Something
like /usr/lib/python/new-module $(pkgname) should do all the
preprocessing.
the
Has anyone started modifying lintian? If I remember correctly,
packages that generate lintian errors will be rejected...
At the moment, lines like
Depends: python1.5
cause an error, E: python-script-but-no-python-dep
Also, someone else reported that lintian complains against
Depends: python (=
On Mon, Oct 29, 2001 at 12:40:33PM +0100, Tom Cato Amundsen wrote:
Has anyone started modifying lintian? If I remember correctly,
packages that generate lintian errors will be rejected...
Lintian is advisory only.
Also, someone else reported that lintian complains against
Depends: python (=
Also, someone else reported that lintian complains against
Depends: python (= 2.1), python ( 2.2)
This is a lintian bug. It's not bothering to notice that one's a less-than
and the other's a greater-than.
Btw, isn't this Depends line problematic anyway? I could have python 1.5
and 2.2
On Oct 27, Gregor Hoffleit wrote:
I've put a version 0.3.6 of the Python Policy Draft on
http://people.debian.org/~flight/python/. The version is still a little
bit rough and sometimes incomplete, but it already gives a good outline
of the Python packaging system we are installing just now
Gregor Hoffleit [EMAIL PROTECTED] writes:
I've put a version 0.3.6 of the Python Policy Draft on
http://people.debian.org/~flight/python/. The version is still a little
bit rough and sometimes incomplete, but it already gives a good outline
of the Python packaging system we are installing
Jérôme Marant writes:
Gregor Hoffleit [EMAIL PROTECTED] writes:
I've put a version 0.3.6 of the Python Policy Draft on
http://people.debian.org/~flight/python/. The version is still a little
bit rough and sometimes incomplete, but it already gives a good outline
of the Python packaging
Matthias Klose [EMAIL PROTECTED] writes:
It let's a package depend on:
python (= 2.1), python ( 2.2), python-foo
and can expect a working default Python version, which has support for
python-foo.
You mean
python, python-foo
I presume?
My proposal would be to build 1.5 and 2.0
Joel Rosdahl writes:
Matthias Klose [EMAIL PROTECTED] writes:
It let's a package depend on:
python (= 2.1), python ( 2.2), python-foo
and can expect a working default Python version, which has support for
python-foo.
You mean
python, python-foo
I presume?
You may
Chris Lawrence writes:
- I'm not sure in 2.1.2.2 that /usr/lib/python/site-packages is a good
name... maybe /usr/share/python/site-packages instead. (After all,
the things should be arch independent.) I'd be happy to code up the
symlink thingamajig for 2.1.2.2 if nobody's working on it.
See
Matthias Klose [EMAIL PROTECTED] writes:
2.1.1 Support Only The Default Version
+ does this Depends: python (= X.Y), python ( X.Y+1) really
work since versioned provides do not exist yet? Isn't it
python-base rather than python ?
yes. python is a real package now. It is a
Gregor Hoffleit [EMAIL PROTECTED] writes:
If nobody find fundamental show-stoppers that render this unusable,
we're going to submit it to Debian Policy very soon.
I think we could also add a section about how to use distutils
to install things in the right place.
My 2 eurocents,
Jérôme Marant writes:
Matthias Klose [EMAIL PROTECTED] writes:
2.1.1 Support Only The Default Version
+ does this Depends: python (= X.Y), python ( X.Y+1) really
work since versioned provides do not exist yet? Isn't it
python-base rather than python ?
yes. python
From Appendix B.2:
The new packages will conflict with every Python dependent
package, that does depend on `python', `python-base', without
depending on `python ( 1.6)' or `python-base ( 2.1)'.
Since the new packages conflict with python-base itself, they don't
need to
Matthias Klose [EMAIL PROTECTED] writes:
It already exists:
deb http://ftp-master.debian.org/~doko/python ./
So, it will exist soon.
s/major//. Correct. Assume we release woody with python (2.1), and we
But I don't want all my python packages to be uninstalled because
Carey Evans writes:
From Appendix B.2:
The new packages will conflict with every Python dependent
package, that does depend on `python', `python-base', without
depending on `python ( 1.6)' or `python-base ( 2.1)'.
Since the new packages conflict with python-base
Jérôme Marant writes:
Matthias Klose [EMAIL PROTECTED] writes:
But I don't want all my python packages to be uninstalled because
python changed. This is unacceptable.
So you simply set the new python packages on hold, until all packages
you need are converted. What's wrong with
On Sun, Oct 28, 2001 at 02:57:15PM +0100, Jérôme Marant wrote:
Matthias Klose [EMAIL PROTECTED] writes:
2.1.1 Support Only The Default Version
[...]
+ a new change to the major version of python, will make all
packages depending on the default version being uninstalled, right?
G'day,
Gregor's already answered most of these, but thought I'd throw in a comment
or two.
On Sun, Oct 28, 2001 at 12:11:04AM -0500, Chris Lawrence wrote:
On Oct 27, Gregor Hoffleit wrote:
I've put a version 0.3.6 of the Python Policy Draft on
http://people.debian.org/~flight/python
I've put a version 0.3.6 of the Python Policy Draft on
http://people.debian.org/~flight/python/. The version is still a little
bit rough and sometimes incomplete, but it already gives a good outline
of the Python packaging system we are installing just now.
Please have a look at the document
Matthias Klose [EMAIL PROTECTED] writes:
Jérôme Marant writes:
I do propose that we install all architecture independant modules
in /usr/share and all architecture dependent modules in /usr/lib
as it has always been.
assume we have a package with an architecture independant module
On Wed, Oct 10, 2001 at 10:28:58AM -0700, Neil Schemenauer wrote:
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
On Sun, Sep 30, 2001 at 01:52:00PM -0700, Neil Schemenauer wrote:
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
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.
That's good news. I'm itching to try out some of the new features. Would I
be able to assist in
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
201 - 230 of 230 matches
Mail list logo
