[Steve Langasek, 23.03.2007]
On Fri, Mar 23, 2007 at 09:58:18AM +0100, Piotr Ożarowski wrote:
- relying on Build-Depends to indicate whether a package builds current
or
all doesn't seem to leave a way to differentiate between packages that
follow the new policy and really /are/
[Pierre Habouzit, 23.03.2007]
current in X?-P-V sucks a lot because X?-P-V explains which python
version the package supports, whereas current is not about that but
about the kind of packaging ways it has. This information should never
have been folded in the same field, I only recently got
Le vendredi 23 mars 2007 à 13:40 +0100, Piotr Ożarowski a écrit :
XB-Python-Type: multiple (compile for all installed [and supported by
the package] Python versions) or single (only for one Python version)
That looks good to me
And how do you ensure that this matches what's actually
On Fri, Mar 23, 2007 at 05:08:22PM +0100, Josselin Mouette wrote:
Le vendredi 23 mars 2007 à 13:40 +0100, Piotr Ożarowski a écrit :
XB-Python-Type: multiple (compile for all installed [and supported by
the package] Python versions) or single (only for one Python version)
That looks
On Fri, Mar 23, 2007 at 06:47:03PM +0100, Piotr Ożarowski wrote:
[Pierre Habouzit, 23.03.2007]
On Fri, Mar 23, 2007 at 05:08:22PM +0100, Josselin Mouette wrote:
Le vendredi 23 mars 2007 à 13:40 +0100, Piotr Ożarowski a écrit :
XB-Python-Type: multiple (compile for all installed [and
Le jeudi 22 mars 2007 à 16:12 +1100, Ben Finney a écrit :
Pierre Habouzit [EMAIL PROTECTED] writes:
Why would you prevent the user to bytecompile your package for every
python version he choose to install ? I see the point to avoid archive
bloat in not building every binary extension.
Le mercredi 21 mars 2007 à 19:13 -0700, Steve Langasek a écrit :
You implemented a tool that *ignored* some of the use cases that went into
the initial policy, among them the case for 'current'.
This is wrong. Python-support doesn't rely on anything else than what
the maintainer chooses to
Twas brillig at 19:13:19 21.03.2007 UTC-07 when Steve Langasek did gyre and
gimble:
SL You implemented a tool that *ignored* some of the use cases that went into
SL the initial policy, among them the case for 'current'.
Please, give us a link to the *written* use cases, so we can map them to
* Pierre Habouzit [EMAIL PROTECTED] [2007-03-21 21:49:00 +0100]:
On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
it's useful for Python applications that need specific Python version.
f.e. if current Python version is 2.4 and my app. will work only with
python2.5 and
[Tristan Seligmann, 22.03.2007]
* Pierre Habouzit [EMAIL PROTECTED] [2007-03-21 21:49:00 +0100]:
On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
it's useful for Python applications that need specific Python version.
f.e. if current Python version is 2.4 and my app.
On Thu, Mar 22, 2007 at 01:36:08PM +0100, Piotr Ożarowski wrote:
[Tristan Seligmann, 22.03.2007]
* Pierre Habouzit [EMAIL PROTECTED] [2007-03-21 21:49:00 +0100]:
On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
it's useful for Python applications that need specific Python
Le jeudi 22 mars 2007 à 14:50 +0100, Pierre Habouzit a écrit :
exactly, putting current is just yet-another-place where the
maintainers declares that he will only prepare the package for current
python. And you're right, python-(all-?)-dev is a already here to give a
hint to the dh_tool
On Thu, Mar 22, 2007 at 07:50:35PM +0100, Josselin Mouette wrote:
Le jeudi 22 mars 2007 à 14:50 +0100, Pierre Habouzit a écrit :
exactly, putting current is just yet-another-place where the
maintainers declares that he will only prepare the package for current
python. And you're right,
On Thu, Mar 22, 2007 at 01:36:08PM +0100, Piotr Ożarowski wrote:
[Tristan Seligmann, 22.03.2007]
* Pierre Habouzit [EMAIL PROTECTED] [2007-03-21 21:49:00 +0100]:
On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
it's useful for Python applications that need specific Python
Hi,
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary it includes:
* the deprecation of the current keyword;
* making Provides: meaningful in the case of inter-module
Le mercredi 21 mars 2007 à 20:22 +0100, Josselin Mouette a écrit :
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary it includes:
* the deprecation of the current keyword
[Josselin Mouette, 21.03.2007]
* the deprecation of the current keyword;
current keyword is deprecated? Why? I'm using it a lot and I like
it...
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpeuiDfwvZtU.pgp
Description: PGP signature
On Wed, Mar 21, 2007, Josselin Mouette wrote:
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary it includes:
* the deprecation of the current keyword;
* making Provides
[Pierre Habouzit, 21.03.2007]
On Wed, Mar 21, 2007 at 08:28:47PM +0100, Piotr Ożarowski wrote:
current keyword is deprecated? Why? I'm using it a lot and I like
it...
What are you using it for exactly ? I mean, please give an example,
with an actual package, that would be okay. Because
On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
[Pierre Habouzit, 21.03.2007]
On Wed, Mar 21, 2007 at 08:28:47PM +0100, Piotr Ożarowski wrote:
current keyword is deprecated? Why? I'm using it a lot and I like
it...
What are you using it for exactly ? I mean, please
[Pierre Habouzit, 21.03.2007]
On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
it's useful for Python applications that need specific Python version.
f.e. if current Python version is 2.4 and my app. will work only with
python2.5 and above, I can Build-depend on
On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote:
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary it includes:
* the deprecation of the current keyword;
So
Le mercredi 21 mars 2007 à 14:44 -0700, Steve Langasek a écrit :
On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote:
I think it's time to update the python policy with the progress that has
been made in how we build python packages. The proposed diff is
attached. In summary
[Steve Langasek, 21.03.2007]
So with current deprecated, what is the solution for a package which wants
to build a single binary extension for the current python version in a
package named python-foo, with no support for other versions of python
returned by pyversions -s?
I think depending on
Le mercredi 21 mars 2007 à 14:51 -0700, Steve Langasek a écrit :
On Wed, Mar 21, 2007 at 10:47:37PM +0100, Josselin Mouette wrote:
If this is a public extension, this goes completely against the spirit
of the policy and should not be allowed. It just means more packages
having to migrate
On Wed, Mar 21, 2007 at 10:38:30PM +0100, Piotr Ożarowski wrote:
[Pierre Habouzit, 21.03.2007]
On Wed, Mar 21, 2007 at 09:25:52PM +0100, Piotr Ożarowski wrote:
it's useful for Python applications that need specific Python version.
f.e. if current Python version is 2.4 and my app. will
On Wed, Mar 21, 2007 at 11:03:37PM +0100, Josselin Mouette wrote:
Le mercredi 21 mars 2007 à 14:51 -0700, Steve Langasek a écrit :
On Wed, Mar 21, 2007 at 10:47:37PM +0100, Josselin Mouette wrote:
If this is a public extension, this goes completely against the spirit
of the policy and
On Wed, Mar 21, 2007 at 03:14:27PM -0700, Steve Langasek wrote:
On Wed, Mar 21, 2007 at 11:03:37PM +0100, Josselin Mouette wrote:
Le mercredi 21 mars 2007 à 14:51 -0700, Steve Langasek a écrit :
On Wed, Mar 21, 2007 at 10:47:37PM +0100, Josselin Mouette wrote:
If this is a public
On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote:
[Steve Langasek, 21.03.2007]
So with current deprecated, what is the solution for a package which wants
to build a single binary extension for the current python version in a
package named python-foo, with no support for other
On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote:
On Wed, Mar 21, 2007 at 02:44:29PM -0700, Steve Langasek wrote:
On Wed, Mar 21, 2007 at 08:22:32PM +0100, Josselin Mouette wrote:
I think it's time to update the python policy with the progress that has
been made in how we
On Wed, Mar 21, 2007 at 03:51:20PM -0700, Steve Langasek wrote:
On Wed, Mar 21, 2007 at 11:16:14PM +0100, Pierre Habouzit wrote:
If we don't, I don't see the purpose of the policy alltogether.
Allowing transitions between default versions of python without package
renames, bypassing NEW,
[Steve Langasek, 21.03.2007]
On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote:
I think depending on python-dev for current only modules/apps and
python-all-dev for the rest should be enough (if both systems will
recognize it correctly, I mean also:
On Thu, Mar 22, 2007 at 12:23:59AM +0100, Piotr Ożarowski wrote:
[Steve Langasek, 21.03.2007]
On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote:
I think depending on python-dev for current only modules/apps and
python-all-dev for the rest should be enough (if both systems
interested to know which process I have hijacked. I have not
contributed to python policy changes since the new policy madness has
started, and I haven't forced anyone to implement things. I've just
implemented a tool that does things *correctly* and helps other
maintainers in this maelstrom
-d *should* be used. There is of course nothing that stops
a maintainer from invoking pyversions -d manually; the question is, how will
doing so fit into the python policy, will there be support for automating
this in the helper tools, and will packages that do this (and are therefore
binNMUable
[Pierre Habouzit, 22.03.2007]
On Thu, Mar 22, 2007 at 12:23:59AM +0100, Piotr Ożarowski wrote:
[Steve Langasek, 21.03.2007]
On Wed, Mar 21, 2007 at 10:59:40PM +0100, Piotr Ożarowski wrote:
I think depending on python-dev for current only modules/apps and
python-all-dev for the rest
On Thu, Mar 22, 2007 at 12:36:07AM +0100, Pierre Habouzit wrote:
* set XB-Python-Version to current, 2.5 # here current can't be
deprecated,
but this field should be filled automatically (think ${python:Versions})
so maintainer doesn't have to know about current
current,
the reverse situation also
holds.
And as a matter of a fact, maintainers do not seem to understand what
current is for, Piotr python2.5-only package is a very good example of
this IMHO.
the question is, how will
doing so fit into the python policy, will there be support for automating
On Thu, Mar 22, 2007 at 12:53:27AM +0100, Piotr Ożarowski wrote:
[Pierre Habouzit, 22.03.2007]
On Thu, Mar 22, 2007 at 12:23:59AM +0100, Piotr Ożarowski wrote:
* set XB-Python-Version to current, 2.5 # here current can't be
deprecated,
but this field should be filled
muddled at present, but
I don't think that points to a technical flaw.
the question is, how will
doing so fit into the python policy, will there be support for automating
this in the helper tools, and will packages that do this (and are therefore
binNMUable for python transitions
Pierre Habouzit [EMAIL PROTECTED] writes:
On Thu, Mar 22, 2007 at 12:53:27AM +0100, Piotr Ożarowski wrote:
How will python-system know to recompile it just for one version
and not for all supported ones?
Why would you prevent the user to bytecompile your package for every
python version
Le mercredi 31 janvier 2007 à 14:15 -0600, Carlo Segre a écrit :
Hello All;
Section B.2 of the Python Policy shows a code snippet that indicates you
need to use dh_python after dh_pycentral. According to the dh_python man
page it is deprecated so this should be changed.
In addition
On Wed, 31 Jan 2007, Josselin Mouette wrote:
Le mercredi 31 janvier 2007 à 14:15 -0600, Carlo Segre a écrit :
I presume that this must also be changed to read that the maintainer has
to install private modules explicitly.
The most accurate documentation you can find (apart from specific
with the new Python policy
A package developers view
Manoj Srivastava
Developer
The Debian Project
Copyright (c) 2006 Manoj Srivastava
Revision History
Revision 1.0.5 4^th November 2006
Revision 1.0.4 12 Aug 2006
Revision 1.0.3
is still in the archive (naturally, since bar uses it),
other later versions may be available but are irrelevant; for our purposes,
assume that foo is simple enough that it's compatible with all versions of
python, past and present.
Under 4.6 of the draft python policy, python-foo does not declare any
On Sun, 13 Aug 2006 23:03:13 -0700, Steve Langasek [EMAIL PROTECTED] said:
On Sun, Aug 13, 2006 at 07:56:09PM -0500, Manoj Srivastava wrote:
OK, I see I have to dot the i's and cross the t's for this case
here. So, here is the scenario: package python-foo packages a
public pure python
Hi,
I have some more thoughts to offer on the example Steve
presented: in essence, he is talking about a package that has become
incompatible with the version that was in stable.
On Sun, 13 Aug 2006 23:03:13 -0700, Steve Langasek [EMAIL PROTECTED]
said:
On Sun, Aug 13, 2006 at
On Sat, Aug 12, 2006 at 12:10:07PM -0500, Manoj Srivastava wrote:
3.1.3. Provides
Packages with public modules and extensions should be named, or
should provide, python-foo. Pure Python public modules that support
all Python versions need not have a Provides field.
... unless there
On Sun, 13 Aug 2006 00:01:37 -0700, Steve Langasek [EMAIL PROTECTED] said:
On Sat, Aug 12, 2006 at 12:10:07PM -0500, Manoj Srivastava wrote:
3.1.3. Provides
Packages with public modules and extensions should be named, or
should provide, python-foo. Pure Python public modules that
On Sun, Aug 13, 2006 at 03:32:27AM -0500, Manoj Srivastava wrote:
On Sun, 13 Aug 2006 00:01:37 -0700, Steve Langasek [EMAIL PROTECTED] said:
On Sat, Aug 12, 2006 at 12:10:07PM -0500, Manoj Srivastava wrote:
3.1.3. Provides
Packages with public modules and extensions should be named, or
On Sun, 13 Aug 2006 10:28:43 -0700, Steve Langasek [EMAIL PROTECTED] said:
On Sun, Aug 13, 2006 at 03:32:27AM -0500, Manoj Srivastava wrote:
On Sun, 13 Aug 2006 00:01:37 -0700, Steve Langasek
[EMAIL PROTECTED] said:
On Sat, Aug 12, 2006 at 12:10:07PM -0500, Manoj Srivastava wrote:
Le dim 13 août 2006 22:17, Manoj Srivastava a écrit :
As to the BOF thing, I'll bite: Why one earth did the bof come
up with design decisiosn that require every single goldarned python
module package to be reuploaded every time a new version of python
is added or removed?
Hi,
OK, I see I have to dot the i's and cross the t's for this
case here. So, here is the scenario: package python-foo packages a
public pure python module. Package bar imports the module
foo. Package baz is a package not yet written that would be written
for Python2.6 that would
:
^^
/usr/share/pycentral
/usr/share/python-support
These location are tool specific and should not be referenced
explicitely in the packaging scripts (debian/rules)
2. Goals of the new Python policy
The new policy is designed to reduce the load on people
Le sam 12 août 2006 17:34, Matthias Klose a écrit :
Manoj Srivastava writes:
policy document. The current version, and future updates, are to
be found at http://www.golden-gryphon.com/software/manoj-policy/
unreachable, comments for the posted text follow
doh, that works for me ?!
-policy/python-policy.xml,
and are now licensed under th GPL (for some reason, docbook article
mode suppresses LegalNotice).
I am including a text version below.
manoj
Packaging with the new Python policy
A package developers view
Manoj Srivastava
Le mar 8 août 2006 21:33, Joe Wreschnig a écrit :
It's possible to build Python modules for all versions with only
python-dev, if they are pure Python modules (feedparser is such a
package, its dependency on python-all-dev is extraneous and could be
just python-dev). So simply looking at the
Le mar 8 août 2006 00:18, Pierre Habouzit a écrit :
§ 2.3.3, 2.4.2, 2.5.3, 2.6.2:
*here* the python$version alternative is correct,
because /extensions/ can be used with a '/usr/bin/python' as soon
as the python current version is in their supported range.
so take the previous
On Tue, 2006-08-08 at 13:41 +0200, Pierre Habouzit wrote:
Le mar 8 août 2006 00:18, Pierre Habouzit a écrit :
current explicitely says that the package is only built for the current
python version, and not for any other supported in debian. But I don't
like that value for the following
Hi,
Another day, another draft.
Here is the latest update for my take on the new Python
policy document. The current version, and future updates, are to be
found at http://www.golden-gryphon.com/software/manoj-policy/
I am including a text version below
Hi,
Here is round two of my take on python policy. I have
incorporate the correction offered by various people, and read the
documents for python-central and python-support, and incorporated my
understanding of those into this document.
So, this is my take on the new python
/var/lib/python-support/pythonX.Y /usr/share/python-support
Note that these two contain the same modules. The /usr/share
directory isn't read by python, only the generated tree in /var is.
Thanks, I'll explicitly make a note of that in that section.
The new python policy places certain
SELinux related packages
which have a python component are compliant with the new Python
policy[1]. The wiki page for the policy[2] seems to be mostly a dh_python
usage manual, and defers to dh_python to set up the variable
substitutions correctly, so I have been trying to write up my own
to that list]
I have been trying to ensure that my SELinux related packages which
have a python component are compliant with the new Python
policy[1]. The wiki page for the policy[2] seems to be mostly a
dh_python usage manual, and defers to dh_python to set up the
variable substitutions correctly, so
Package: pyro
Version: 3.5-1
Severity: important
Tags: patch
Hi Cédric,
The pyro package currently does not follow the new Python policy
(http://wiki.debian.org/DebianPython/NewPolicy), but strangely no bug
has been filed against it so far.
The attached patch fixes this, as well
On 6/29/06, Sam Morris [EMAIL PROTECTED] wrote:
On Thu, 29 Jun 2006 16:25:17 +0200, Pierre Habouzit wrote:
Le mer 28 juin 2006 23:20, Raphael Hertzog a écrit :
So you don't have any excuse to not update your packages any more.
About 60% of the Python modules have already been updated, but
On Wed, 28 Jun 2006, Raphael Hertzog wrote:
We also have many python applications (or badly packaged modules which
have not been caught by the first mass-bug filing) that have a dependency
python ( 2.4) and that needs to be updated as well. Please find the
list below (~150 packages). The
Le mer 28 juin 2006 23:20, Raphael Hertzog a écrit :
So you don't have any excuse to not update your packages any more.
About 60% of the Python modules have already been updated, but 109
are left to be done:
http://bugs.debian.org/from:[EMAIL PROTECTED]
The bugs have been filled two weeks
On Thu, 29 Jun 2006 16:25:17 +0200, Pierre Habouzit wrote:
Le mer 28 juin 2006 23:20, Raphael Hertzog a écrit :
So you don't have any excuse to not update your packages any more.
About 60% of the Python modules have already been updated, but 109
are left to be done:
Le jeu 29 juin 2006 16:37, Sam Morris a écrit :
On Thu, 29 Jun 2006 16:25:17 +0200, Pierre Habouzit wrote:
Le mer 28 juin 2006 23:20, Raphael Hertzog a écrit :
So you don't have any excuse to not update your packages any more.
About 60% of the Python modules have already been updated, but
Hello Debian Python!
I maintain python-goopy and harvestman packages, which (may) need to
be updated to conform to the new Python policy. Unfortunately, I won't
be back at my Sid machine till August, and I can't do anything about
it before that!
In any case, I thing goopy will take no tiem
Python Transition Mass bug [EMAIL PROTECTED] writes:
Hi, your package has been detected as generating a python
module/extension that may need an upgrade to the new Python Policy[1].
A wiki page [2] explains what has to be done to upgrade your packages
to the new Policy. This bug may
On Sun, Jun 11, 2006 at 02:35:05PM +0200, Raphael Hertzog wrote:
Hi,
as part of the new policy we should also deprecate /usr/lib/site-python.
I'll have to reread the new policy, but I think this is not a very good
idea. /usr/lib/site-python exists for modules which do not care about
which
On Mon, 12 Jun 2006, Alexandre Fayolle wrote:
Since this directory is in sys.path of all python versions, if we
byte-compile those in-place for the current version, then the modules
won't work with other python versions.
This just not true. Python is smart enough not to use the .pyc if
On Mon, Jun 12, 2006 at 09:20:13AM +0200, Raphael Hertzog wrote:
/usr/lib/site-python is on the sys.path of all python versions so we must
make sure to provide the best (ie .py with working .pyc) for all python
versions.
Why must?
Has this for some reason become a problem just recently or
On Mon, 12 Jun 2006, Juha-Matti Tapio wrote:
On Mon, Jun 12, 2006 at 09:20:13AM +0200, Raphael Hertzog wrote:
/usr/lib/site-python is on the sys.path of all python versions so we must
make sure to provide the best (ie .py with working .pyc) for all python
versions.
Why must?
Well
Hi,
I've prepared this:
http://wiki.debian.org/DebianPython/NewPolicy
Feel free to enhance.
I also converted python-pam as an example (std debhelper package):
http://people.debian.org/~hertzog/python/examples/
I'll gladly put other examples packages at the same place. Just send them
to me.
Coin,
Raphael Hertzog [EMAIL PROTECTED] writes:
Now it's time to ask all maintainers to update their packages. Someone
should prepare several list of source packages:
- python extensions
- python modules only
- python apps
Fact is python-support is not yet ready for extensions, and CDBS
Hi,
as part of the new policy we should also deprecate /usr/lib/site-python.
Since this directory is in sys.path of all python versions, if we
byte-compile those in-place for the current version, then the modules
won't work with other python versions.
Most packages using this directory (like
Ar 11/06/2006 am 14:35, ysgrifennodd Raphael Hertzog:
Someone should file a wishlist bug on lintian to check that packages don't
use /usr/lib/site-python any more.
Done: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=372748
--
Dafydd
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a
On Tue, 2005-10-25 at 08:40, Josselin Mouette wrote:
Le lundi 24 octobre 2005 à 11:30 -0400, James A. Treacy a écrit :
Thanks for the replies to my questions.
I hope that a way to ensure automatic recompiling of python modules is
implemented sometime in the future.
If you want to
Le mardi 25 octobre 2005 à 12:24 +0100, Donovan Baarda a écrit :
If you want to automate the process on the packaging side, using
dh_python will do all the work for you; you will only need a rebuild
when the major python version changes. Support for rebuilding these
modules automatically
On Sat, 2005-10-22 at 22:27, James A. Treacy wrote:
I have some questions relating to python packages and the python
policy.
I maintain a pure python program (gramps) that relies heavily on other
python packages: python-gnome2, python-glade2, python-reportlab and
python-gnome2-extras
Matthias Klose [EMAIL PROTECTED] wrote:
look at the archives. python-central is a step forward, but it doesn't
do anything to solve the forward conflicts for python applications and
modules outside of sys.path.
OK, thanks for the explanation.
--
Florent
--
To UNSUBSCRIBE, email to [EMAIL
On Tue, 2005-07-05 at 02:49, Matthias Klose wrote:
Florent Rougon writes:
Sergio Talens-Oliag [EMAIL PROTECTED] wrote:
OK, then I'll take a look and see if I can write a script to support
it, it
seems quite simple but maybe I'm missing something...
Before you write another
or changes have been proposed for
the
next version of the policy, if any.
This is exactly like the proposal already described but not yet
supported in the current Python Policy. The only difference is it
suggests using /usr/lib/python/site-packages instead of
/usr/lib/site-python
Sergio Talens-Oliag [EMAIL PROTECTED] wrote:
OK, then I'll take a look and see if I can write a script to support it, it
seems quite simple but maybe I'm missing something...
Before you write another script, I think it would be useful to know why
python-central was not adopted. I have
Florent Rougon writes:
Sergio Talens-Oliag [EMAIL PROTECTED] wrote:
OK, then I'll take a look and see if I can write a script to support it,
it
seems quite simple but maybe I'm missing something...
Before you write another script, I think it would be useful to know why
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sergio Talens-Oliag schrieb:
Hello all,
I was reading the last messages to the list and I've noticed that all python
packages I have are pure python and I that I could install them for all
python versions (at least for python =2.3), but
would like to know what do others thing
about it and know what other solutions or changes have been proposed for the
next version of the policy, if any.
This is exactly like the proposal already described but not yet
supported in the current Python Policy. The only difference is it
suggests
Hello all,
I was reading the last messages to the list and I've noticed that all python
packages I have are pure python and I that I could install them for all
python versions (at least for python =2.3), but if I install the code on
/usr/lib/site-python/ the code will only work with the
the Python Policy draft, and found:
A package with a name `python-foo' will always provide the module
foo for the default Debian Python version of the distribution. I.e.
the package will extend the function of `/usr/bin/python' (which is
installed by the package
On Wed, 2004-02-11 at 11:28, Florent Rougon wrote:
There used to be a tool called python-central [...]
It probably doesn't solve the case where you need a certain version of
python to run build-time test cases and such. I guess it might have been
a good idea, but since it didn't catch on,
Fabian Fagerholm [EMAIL PROTECTED] wrote:
It probably doesn't solve the case where you need a certain version of
python to run build-time test cases and such. I guess it might have been
a good idea, but since it didn't catch on, perhaps it was too
complicated.
Build-time tests are run, well,
On Wed, 2004-02-11 at 02:14, Graham Wilson wrote:
I think I'll do this for python-albatross as well. It'll be a really
tiny package but at least it'll fix the issue of not being able to
install both python 2.2 and 2.3 versions.
Does it make sense to have both versions installed? Why might
Fabian Fagerholm [EMAIL PROTECTED] wrote:
Hello all,
Hi,
Firstly, it seems a little silly to duplicate all the code in both
packages. I guess there's really no other way of doing it, since there
There used to be a tool called python-central (look in the mailing list
archives) that allowed
On Tue, 2004-02-10 at 20:44, Graham Wilson wrote:
This is the solution I use with the PyX package is to create a
python-pyx-common package that both of the versioned packages depend on.
This works fine for PyX, since the -common package just cotains
read-only data files. I am not sure how well
On Tue, Feb 10, 2004 at 08:54:43PM +0200, Fabian Fagerholm wrote:
On Tue, 2004-02-10 at 20:44, Graham Wilson wrote:
This is the solution I use with the PyX package is to create a
python-pyx-common package that both of the versioned packages depend on.
This works fine for PyX, since the
I remember seeing a draft Python policy some time ago but it is not
linked from http://www.debian.org/devel/
The reason I am looking for it is that I need to decide what to do with
the postgresql package.
The current package (7.3.4-8) contains the binary packages
python-pygresql and python{x.x
Oliver Elphick writes:
I remember seeing a draft Python policy some time ago but it is not
linked from http://www.debian.org/devel/
see /usr/share/doc/python. It currently in a proposed state, I think
we won't submit it as formal policy for sarge.
The reason I am looking for it is that I need
101 - 200 of 230 matches
Mail list logo
