Hi,
This is version 1.05 of the draft, now with typo fixes, and
some initial policy support for partial upgrades for pure python
public modules that are trying to drop support for older versions of
python. The idea is that error cases are minimized if we do not drop
a version of
Manoj Srivastava [EMAIL PROTECTED] writes:
Copyright (c) 2006 Manoj Srivastava
Revision History
Revision 1.0.5 4^th November 2006
Setember?
--
O T A V I OS A L V A D O R
-
Le samedi 26 août 2006 à 00:16 +0200, Mike Hommey a écrit :
You can put them wherever you want as long as this complies with the FHS
and that a set of .rtupdate/.rtinstall/.rtremove scripts take care of
them. This is one of the only things that are currently standardized.
Wasn't it
On Sat, Aug 26, 2006 at 11:21:26AM +0200, Josselin Mouette [EMAIL PROTECTED]
wrote:
Le samedi 26 août 2006 à 00:16 +0200, Mike Hommey a écrit :
You can put them wherever you want as long as this complies with the FHS
and that a set of .rtupdate/.rtinstall/.rtremove scripts take care of
On Fri, Aug 25, 2006 at 11:34:51PM +0200, Josselin Mouette wrote:
Le vendredi 25 août 2006 à 23:11 +0200, Mike Hommey a écrit :
The problem with the python policy is that there is no policy as to
where the modules are supposed to be installed. Depending on the tool
you are using
Le samedi 26 août 2006 à 08:43 +0200, Wouter Verhelst a écrit :
You can put them wherever you want as long as this complies with the FHS
and that a set of .rtupdate/.rtinstall/.rtremove scripts take care of
them. This is one of the only things that are currently standardized.
So why not
On Thu, Aug 24, 2006 at 11:46:25PM +0200, Josselin Mouette wrote:
Let me rephrase it: the internals of python-support, and how it helps
implementing the python policy, are developed in the python-support
documentation. They don't need to be part of the policy
Yes they do.
and they have
Le vendredi 25 août 2006 à 13:01 +0200, Wouter Verhelst a écrit :
I can't speak for others, but python-support provides
pysupport-movemodules and pysupport-parseversions to separate the
debhelper snippet from the actual abstraction code.
That is still not what is required. Unless these
On Fri, Aug 25, 2006 at 10:22:10PM +0200, Josselin Mouette [EMAIL PROTECTED]
wrote:
Le vendredi 25 août 2006 à 13:01 +0200, Wouter Verhelst a écrit :
I can't speak for others, but python-support provides
pysupport-movemodules and pysupport-parseversions to separate the
debhelper snippet
Le vendredi 25 août 2006 à 23:11 +0200, Mike Hommey a écrit :
The problem with the python policy is that there is no policy as to
where the modules are supposed to be installed. Depending on the tool
you are using (python-support or python-central), the directory is
different. Where is someone
On Fri, Aug 25, 2006 at 11:34:51PM +0200, Josselin Mouette [EMAIL PROTECTED]
wrote:
Le vendredi 25 août 2006 à 23:11 +0200, Mike Hommey a écrit :
The problem with the python policy is that there is no policy as to
where the modules are supposed to be installed. Depending on the tool
you
Le mercredi 23 août 2006 à 15:39 +0300, Lars Wirzenius a écrit :
The location is specific to the packaging tool and shouldn't be
mentioned in the policy.
Sure, that's fine: no need to mention it in policy. What was said
earlier in the thread was that the locations should not be referenced
to, 2006-08-24 kello 16:25 +0200, Josselin Mouette kirjoitti:
Le mercredi 23 août 2006 à 15:39 +0300, Lars Wirzenius a écrit :
The location is specific to the packaging tool and shouldn't be
mentioned in the policy.
Sure, that's fine: no need to mention it in policy. What was said
On Thu, Aug 24, 2006 at 05:56:07PM +0300, Lars Wirzenius wrote:
installed, can't be put into the Policy. The Policy editor, and those of
use who don't want to use debhelper, insist that writing policy based on
debhelper tools is not acceptable.
Not just those who don't want to use debhelper.
Le jeudi 24 août 2006 à 17:56 +0300, Lars Wirzenius a écrit :
Round and round we go.
The people writing the dh_* snippets insist that the details of how they
work, such as locations in which Python modules should actually be
installed, can't be put into the Policy. The Policy editor, and
On Thu, 24 Aug 2006 23:46:25 +0200, Josselin Mouette [EMAIL PROTECTED] said:
Le jeudi 24 août 2006 à 17:56 +0300, Lars Wirzenius a écrit :
Round and round we go.
The people writing the dh_* snippets insist that the details of how
they work, such as locations in which Python modules should
Le samedi 12 août 2006 à 19:29 +0300, Lars Wirzenius a écrit :
la, 2006-08-12 kello 18:10 +0200, Pierre Habouzit kirjoitti:
/usr/share/pycentral
/usr/share/python-support
These location are tool specific and should not be referenced
explicitely in the
ke, 2006-08-23 kello 10:46 +0200, Josselin Mouette kirjoitti:
Le samedi 12 août 2006 à 19:29 +0300, Lars Wirzenius a écrit :
la, 2006-08-12 kello 18:10 +0200, Pierre Habouzit kirjoitti:
/usr/share/pycentral
/usr/share/python-support
These location are
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 module. Package bar imports the module
foo. Package baz is a package
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 Mon, 14 Aug 2006 09:36:29 -0500, Manoj Srivastava
[EMAIL PROTECTED] said:
Hate following up my own message. This is a biased recap of a
discussion Steve ands I had on IRC, and ou should wait his response
before taking my version of the discussion without a grain of salt.
On
On Sat, 12 Aug 2006 16:57:52 -0600, Bruce Sass [EMAIL PROTECTED] said:
On Sat August 12 2006 09:34, Matthias Klose wrote: First time I've
seen the design goals laid out like this. Thanks, and sorry if this
is out of place.
No, not the whole design goal. Although the document is titled
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
On Sun, 2006-08-13 at 19:56 -0500, Manoj Srivastava wrote:
Here there are two cases. Either module foo can't be written at all
for version 2.6, or it the same functionality can be provided with
This is a little simplistic.
The parser changes fairly routinely in python versions. This
On Sun, 13 Aug 2006 23:37:15 +0200, Pierre Habouzit [EMAIL PROTECTED] said:
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
On Mon, 14 Aug 2006 11:21:07 +1000, Robert Collins [EMAIL PROTECTED] said:
On Sun, 2006-08-13 at 19:56 -0500, Manoj Srivastava wrote:
Here there are two cases. Either module foo can't be written at all
for version 2.6, or it the same functionality can be provided with
This is a little
la, 2006-08-12 kello 18:10 +0200, Pierre Habouzit kirjoitti:
/usr/share/pycentral
/usr/share/python-support
These location are tool specific and should not be referenced
explicitely in the packaging scripts (debian/rules)
agreed
python-support seems to require
On Sat August 12 2006 09:34, Matthias Klose wrote:
First time I've seen the design goals laid out like this. Thanks, and
sorry if this is out of place.
No, not the whole design goal. Although the document is titled
developer's view, the other goals should be mentioned as well.
These are
Le sam 12 août 2006 17:34, Matthias Klose a écrit :
dh_pysupport doesn't
use this information, but requires the developer to explicitely pass
the directory containing the extension module.
that's not completely true, it only searches in /usr/lib/$pkg,
/usr/share/$pkg, /usr/lib/games/$pkg and
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
1.1. Categorization of Python software
Program/script
This
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 ?!
On Sat, 12 Aug 2006 17:34:06 +0200, Matthias Klose [EMAIL PROTECTED] said:
Manoj Srivastava writes:
policy document. The current version, and future updates, are to be
found at http://www.golden-gryphon.com/software/manoj-policy/
Unfortunately, you are commenting on an old version of
Le mer 9 août 2006 01:33, Manoj Srivastava a écrit :
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/
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
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
my changes proposals follow. {+ +} are part I've actually modified.
Le lun 7 août 2006 21:42, Manoj Srivastava a écrit :
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
On Mon, Jul 31, 2006, Manoj Srivastava wrote:
2.1. [5]XS-Python-Version:
2.2. [6]XB-Python-Version:
Your document keeps mentionning these, even as requirements, but XB-
isn't required for packages using python-support, and XS can be
replaced by
Roberto C. Sanchez [EMAIL PROTECTED] wrote:
Not sure if I missed it, but you seem to claim a copyright but not give
an explicit license. I imagine you meant to put it under GPL or a free
version of the GFDL. Could you please clarify and also add it to the
document?
I couldn't care less
Le lundi 31 juillet 2006 à 21:10 -0500, Manoj Srivastava a écrit :
Public modules are available for use in other Python scripts or
modules using the import directive. They are installed in one of
the directories
Frank Küster wrote:
Roberto C. Sanchez [EMAIL PROTECTED] wrote:
Not sure if I missed it, but you seem to claim a copyright but not give
an explicit license. I imagine you meant to put it under GPL or a free
version of the GFDL. Could you please clarify and also add it to the
document?
On Tue, 01 Aug 2006 09:55:39 +0200, Josselin Mouette [EMAIL PROTECTED] said:
Le lundi 31 juillet 2006 à 21:10 -0500, Manoj Srivastava a écrit :
Public modules are available for use in other Python scripts or
modules using the import directive. They are installed in one of
the directories
On Tue, 1 Aug 2006 09:35:56 +0200, Loïc Minier [EMAIL PROTECTED] said:
On Mon, Jul 31, 2006, Manoj Srivastava wrote:
2.1. [5]XS-Python-Version: 2.2. [6]XB-Python-Version:
Your document keeps mentionning these, even as requirements, but
XB- isn't required for packages using python-support,
On Tue, Aug 01, 2006, Manoj Srivastava wrote:
Could you point me to documentation on python-support, what it
does, how to use it, and how it differs from python-central?
Well, python-support is documented at the expected
/usr/share/doc/python-support and in the dh_pysupport man page.
Le mardi 01 août 2006 à 09:45 -0500, Manoj Srivastava a écrit :
Public extensions should be packaged with a name of python-foo,
where foo is the name of the module. Such a package should support
the current Debian Python version, and more if possible.
Maybe a word on how public
Hi,
I have finished my initial analysis of Python policy and
dh_python, and created a rough specification of what the python
policy is supposed to be (based on current dh_python behaviour). The
current analysis, and future updates, are to be found at
http://www.golden-gryphon.com
Manoj Srivastava wrote:
Hi,
I have finished my initial analysis of Python policy and
dh_python, and created a rough specification of what the python
policy is supposed to be (based on current dh_python behaviour). The
current analysis, and future updates, are to be found
53 matches
Mail list logo
