Hi Geert!
On Sun, Jul 05, 2020 at 07:05:28PM +0200, Geert Stappers wrote:
> Hi,
>
> Where to find the source of python-policy?
I believe it is here:
https://salsa.debian.org/cpython-team/python3-defaults/-/blob/master/debian/python-policy.dbk
--
Dmitry Shachnev
signature.asc
Description: PGP
Scott Kitterman writes:
> On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote:
> > Ben Finney writes:
> > > * Address all the language around Python 2 versus Python 3 versus
> > > Python general, and re-order or re-word to focus *primarily* on
> > > Python 3, with Python 2 treated as the
On Feb 16, 2016, at 11:54 AM, Paul Wise wrote:
>I always thought it strange to put site- in /usr/local since
>/usr/local already implies site/system-wide packages. Same for dist-
>since /usr already implies distribution packages.
For as long as I can remember, a from-source 'configure && make &&
On Tue, Feb 16, 2016 at 11:42 AM, Barry Warsaw wrote:
> I don't remember exactly why we called it 'site-packages' ...
Thanks for the history :)
I always thought it strange to put site- in /usr/local since
/usr/local already implies site/system-wide packages. Same for dist-
since /usr already imp
On Feb 15, 2016, at 07:42 PM, Barry Warsaw wrote:
>I don't remember exactly why we called it 'site-packages', but I believe it
>was an evolution from the earlier ni.py module, which was where dotted module
>paths first showed up in Python.
And which had a 'site-python' directory, which was kept a
On Feb 16, 2016, at 11:05 AM, Paul Wise wrote:
>Side-note: does anyone know why Python puts packages in "dist-packages",
>"site-packages" etc directories instead of just "packages" directories?
I don't remember exactly why we called it 'site-packages', but I believe it
was an evolution from the e
On Sat, Jan 23, 2016 at 9:55 AM, Barry Warsaw wrote:
> 2.5 Module Path
>
> "Public Python modules must be installed in the system Python modules
> directory, /usr/lib/python./dist-packages. Public Python 3 modules must
> be installed in /usr/lib/python3/dist-packages."
Side-note: does anyone kno
On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote:
> Ben Finney writes:
> > * Address all the language around Python 2 versus Python 3 versus
> >
> > Python general, and re-order or re-word to focus *primarily* on Python
> > 3, with Python 2 treated as the still-supported legacy syst
Ben Finney writes:
> * Address all the language around Python 2 versus Python 3 versus
> Python general, and re-order or re-word to focus *primarily* on Python
> 3, with Python 2 treated as the still-supported legacy system.
>
> I'm maintaining a Bazaar branch for this, feel free to get it::
Scott Kitterman writes:
> On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote:
> ...
> > Once these non-semantic changes are accepted I will begin work on
> > the second stage of semantic changes.
> ...
>
> OK. Those are all accepted.
Thank you, Scott! I'll proceed with the semantic c
On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote:
...
> Once these non-semantic changes are accepted I will begin work on the
> second stage of semantic changes.
...
OK. Those are all accepted. Barry Warsaw had done some changes in the -whl
section so I made an attempt at merging w
Scott Kitterman writes:
> I should be able to get it reviewed and merged no later than Saturday
> (probably Friday).
Much appreciated, thanks for the response.
--
\“When I was a baby I kept a diary. Recently I was re-reading |
`\ it, it said ‘Day 1: Still tired from the move. Day
On January 26, 2016 10:32:57 PM EST, Ben Finney
wrote:
>Dmitry Shachnev writes:
>
>> On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
>> > I'm planning to provide changes in two bundles:
>> >
>> > * Go through the whole document and tidy it up for consistency,
>> > source style, m
Dmitry Shachnev writes:
> On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
> > I'm planning to provide changes in two bundles:
> >
> > * Go through the whole document and tidy it up for consistency,
> > source style, markup, and language style. This should not change
> > the meanin
Hi Ben,
On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote:
> I'm planning to provide changes in two bundles:
>
> * Go through the whole document and tidy it up for consistency, source
> style, markup, and language style. This should not change the meaning
> of anything, but will chang
Ben Finney writes:
> I'm planning to provide changes in two bundles:
>
> * Go through the whole document and tidy it up for consistency, source
> style, markup, and language style. This should not change the meaning
> of anything, but will change the wording of numerous passages.
>
> My pro
Ben Finney writes:
> Scott Kitterman writes:
>
> > At this point I think internal consistency is probably more
> > important, so if someone wants to go through and make all the
> > python's that should be python2, etc then please send in a patch.
>
> I'll take that on.
I'm planning to provide c
On January 24, 2016 11:59:14 PM EST, Ben Finney
wrote:
>Scott Kitterman writes:
>
>> On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
>> > Found it; the source document is ‘python-policy.sgml’ in the source
>> > VCS for ‘python3’. Currently that's a Bazaar repository at
>> >
>.
>>
>>
Scott Kitterman writes:
> On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
> > Found it; the source document is ‘python-policy.sgml’ in the source
> > VCS for ‘python3’. Currently that's a Bazaar repository at
> > .
>
> That's correct.
Hmm, apparently I've got the wrong thing. I've got
Thanks for taking this on Ben,
On Jan 24, 2016, at 04:33 PM, Ben Finney wrote:
>I think you're right that this needs a general clean-up through the
>policy document, to consistently use:
>
>* “python2” to refer to that command only;
>
>* “python3” to refer to that command only;
>
>* “python” to r
On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
> Ben Finney writes:
> > Where is the Git (I assume?) repository you're using for VCS of this
> > policy document?
>
> Found it; the source document is ‘python-policy.sgml’ in the source VCS
> for ‘python3’. Currently that's a Bazaar repos
On Sunday, January 24, 2016 04:33:55 PM Ben Finney wrote:
> Scott Kitterman writes:
> > I don't particularly agree, but if that's correct, then there's a
> > large amount of change needed throughout the policy. These certainly
> > aren't the only places this comes up.
>
> Yes, that's likely becau
On Sunday, January 24, 2016 04:46:09 PM Ben Finney wrote:
> Scott Kitterman writes:
> > I've taken a run through the current Python Policy to see where I
> > think it needs to be updated for Stretch. The updates largely fall
> > into four categories: […]
>
> This is great to see, thank you Scott.
Ben Finney writes:
> Where is the Git (I assume?) repository you're using for VCS of this
> policy document?
Found it; the source document is ‘python-policy.sgml’ in the source VCS
for ‘python3’. Currently that's a Bazaar repository at
.
--
\ “The entertainment industry calls DRM "se
Scott Kitterman writes:
> I've taken a run through the current Python Policy to see where I
> think it needs to be updated for Stretch. The updates largely fall
> into four categories: […]
This is great to see, thank you Scott.
Where is the Git (I assume?) repository you're using for VCS of thi
Scott Kitterman writes:
> I don't particularly agree, but if that's correct, then there's a
> large amount of change needed throughout the policy. These certainly
> aren't the only places this comes up.
Yes, that's likely because when the Debian Python policy was initially
drafted, there was no
On Saturday, January 23, 2016 08:50:49 PM Barry Warsaw wrote:
> On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote:
> >Personally I seriously dislike the trend to call Python Python 2 (and I
> >still thing approving a pep to invent /usr/bin/python2 because Arch went
> >insane was a horrible idea).
On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote:
>Personally I seriously dislike the trend to call Python Python 2 (and I still
>thing approving a pep to invent /usr/bin/python2 because Arch went insane was
>a horrible idea). There's an earlier spot in the document where it says that
>everyth
On Friday, January 22, 2016 05:55:19 PM Barry Warsaw wrote:
> On Jan 21, 2016, at 10:47 AM, Scott Kitterman wrote:
> >I've taken a run through the current Python Policy to see where I think it
> >needs to be updated for Stretch.
>
> Thanks Scott for the badly needed update.
>
> Some comments, apo
On Jan 21, 2016, at 10:47 AM, Scott Kitterman wrote:
>I've taken a run through the current Python Policy to see where I think it
>needs to be updated for Stretch.
Thanks Scott for the badly needed update.
Some comments, apologies for the lack of good quoting, or if I've read the
diff incorrectly
On Oct 22, 2015, at 11:11 AM, IOhannes m zmölnig (Debian/GNU) wrote:
>something else i wonder whether we shouldn't drop it, as i don't quite
>understand why it has to be in the policy.
>
>i *think* it's supposed to urge DDs into becoming team members, even though
>they can ("are able to") already
On Oct 22, 2015, at 11:14 AM, IOhannes m zmölnig (Debian/GNU) wrote:
>thanks for gender neutral wording. however, you missed one "his" in the
>first sentence (probably more in other paragraphs).
Got it, thanks.
-Barry
pgpm4DkniheG1.pgp
Description: OpenPGP digital signature
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2015-10-21 15:54, Barry Warsaw wrote:
> Hopefully, the latest changes (see previous follow up) are both
> more concise and coherent.
maybe.
i have to admit i'm not totally used to an reviewing git patches per
mailinglists, and in this case i got
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2015-10-20 22:53, Barry Warsaw wrote:
> +Any·Debian·developer·who·wishes·to·integrate·his·packages·in·the·team
·can·do
>
>
+so·without·requesting·access·(as·the·repository·is·writable·by·all·DD).
·If·one
> wants·to·be·more·involved·in·the·team,·w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2015-10-20 22:53, Barry Warsaw wrote:
> +Any·Debian·developer·who·wishes·to·integrate·his·packages·in·the·team
·can·do
>
>
+so·without·requesting·access·(as·the·repository·is·writable·by·all·DD).
·If·one
> wants·to·be·more·involved·in·the·team,·w
On 2015-10-21 09:31:04 -0500 (-0500), Ian Cordasco wrote:
> On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw wrote:
> > On Oct 21, 2015, at 08:47 PM, Brian May wrote:
> >
> >>in one case this is because upstream have only supplied a *.whl
> >>file on Pypi.
> >
> > I'm *really* hoping that the PyPA wi
On Wed, Oct 21, 2015 at 8:58 AM, Barry Warsaw wrote:
> On Oct 21, 2015, at 08:47 PM, Brian May wrote:
>
>>in one case this is because upstream have only supplied a *.whl
>>file on Pypi.
>
> I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.
I'm not sure why they should pro
On Oct 21, 2015, at 08:47 PM, Brian May wrote:
>in one case this is because upstream have only supplied a *.whl
>file on Pypi.
I'm *really* hoping that the PyPA will prohibit binary wheel-only uploads.
There is talk about source wheels, and if that happens we'll probably have to
adjust our tools
On Oct 21, 2015, at 09:51 AM, IOhannes m zmölnig (Debian/GNU) wrote:
>i am not a native speaker. so i might get things wrong.
>but i'm not the only non-native English speaker in Debian.
>therefore, i *strongly* suggest that the policy should be written in a
>style that non-natives can understand i
On Oct 21, 2015, at 08:46 AM, Vincent Bernat wrote:
>You should remove the reference to Pypi since tarballs can also be taken
>From GitHub (when upstream doesn't want to ship everything, like tests,
>in Pypi tarballs or doesn't even release tarballs on Pypi):
Yep, done.
-Barry
pgpcjyVfgA4jB.pg
Vincent Bernat writes:
> You should remove the reference to Pypi since tarballs can also be taken
> From GitHub (when upstream doesn't want to ship everything, like tests,
> in Pypi tarballs or doesn't even release tarballs on Pypi):
Have filled upstream bugs on issues that prevent me using the
❦ 20 octobre 2015 20:52 -0400, Barry Warsaw :
>>I'd remove this paragraph. Releases can be made via `git archive` and I did
>>that many times (assuming pristine-tar will still keep needed data to
>>regenerate exact same tarball). If you meant that we don't want to keep
>>complete upstream git h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2015-10-21 02:17, Ben Finney wrote:
> "IOhannes m zmölnig (Debian/GNU)" writes:
>
>> thanks a lot for preparing all this.
>>
>> On 10/20/2015 10:53 PM, Barry Warsaw wrote:
>>> +DPMT requires upstream tarballs; releases cannot be made from
>>> u
On Oct 20, 2015, at 11:30 PM, Piotr Ożarowski wrote:
>I have few comments, but even if I didn't, please wait at least until after
>the weekend (or better: 7 days) so that others have time to review it and
>comment / propose changes.
Fair enough. Of course, it's in a vcs so it's easy to change! :
On Oct 21, 2015, at 11:17 AM, Ben Finney wrote:
>On the contrary, I think the Policy document should document the
>rationale for contingent decisions like this. When it is inevitably
>discussed again in the future, it is always better to know the intent of
>the authors.
+1
Cheers,
-Barry
"IOhannes m zmölnig (Debian/GNU)" writes:
> thanks a lot for preparing all this.
>
> On 10/20/2015 10:53 PM, Barry Warsaw wrote:
> > +DPMT requires upstream tarballs; releases cannot be made from upstream git
> > +repositories directly. This is because PyPI contains upstream tarballs,
> > and
>
[Barry Warsaw, 2015-10-20]
> Latest diff against master. If you're happy with this, I'll merge to master,
> update the web page, and trim the wiki.
I have few comments, but even if I didn't, please wait at least until after
the weekend (or better: 7 days) so that others have time to review it and
thanks a lot for preparing all this.
On 10/20/2015 10:53 PM, Barry Warsaw wrote:
> +DPMT requires upstream tarballs; releases cannot be made from upstream git
> +repositories directly. This is because PyPI contains upstream tarballs, and
> +tarballs are what we upload to the Debian archive.
i fi
Latest diff against master. If you're happy with this, I'll merge to master,
update the web page, and trim the wiki.
Cheers,
-Barry
diff --git a/policy.rst b/policy.rst
index c09f03a..123792c 100644
--- a/policy.rst
+++ b/policy.rst
@@ -1,39 +1,44 @@
-
- P
On Oct 20, 2015, at 05:16 PM, Piotr Ożarowski wrote:
>I will leave this team the moment I have to read README.sources each day when
>I sponsor a package.
Nobody wants that! (either you leaving or having to read README.source for
every package).
Cheers,
-Barry
[Barry Warsaw, 2015-10-20]
> Here's my concern: I don't want too much duplication of information in
> multiple locations. That's a sure recipe for bitrot, and I know no one wants
> to have to edit information in more than one place.
>
> Until now, the wiki has been the more convenient place to ma
[Barry Warsaw, 2015-10-20]
> I also think it would be fine to *eventually* merge the two teams. I suspect
> there isn't really much benefit to keeping them separate and a lot of
> unnecessary cost. Is there anybody on PAPT who doesn't want to be on DPMT?
/me puts his PAPT admin hat on
WHAT? You
[Barry Warsaw, 2015-10-20]
> On Oct 19, 2015, at 09:04 PM, Piotr Ożarowski wrote:
>
> >Debian Python Policy¹ is something every single packages that extends
> >Python should follow. There are many teams (more than 4) each of them
> >can have their own policy that extends DPP.
>
> This is an impor
On Oct 20, 2015, at 12:37 AM, Piotr Ożarowski wrote:
>should we also document that we're not OpenStack Packaging Team?
Or zope-packaging? . Agreed that there are different teams here, but I
am hoping that we can do some consolidation. E.g. I posted on the zope list
that I'd like to pull those p
On Oct 19, 2015, at 09:04 PM, Piotr Ożarowski wrote:
>Debian Python Policy¹ is something every single packages that extends
>Python should follow. There are many teams (more than 4) each of them
>can have their own policy that extends DPP.
This is an important distinction that I don't think is re
Thanks for the feedback Piotr. I've made all the changes you suggest, except
one. I'll discuss that below and include an updated diff against master.
On Oct 19, 2015, at 11:26 PM, Piotr Ożarowski wrote:
>I'm against this change. If we want all team packages to follow some
>rules, these rules ne
[Brian May, 2015-10-20]
> Are DAPT and PAPT the same thing?
no such thing as DAPT
> This information should be documented somewhere.
should we also document that we're not OpenStack Packaging Team?
> In my words, for Debian project there is a wiki and a policy. For each
> team there is a wiki a
Piotr Ożarowski writes:
>> * The Debian wiki
>> https://wiki.debian.org/Python and subpages
>
> wiki is something everyone can edit. It's a place that can help with
> various tasks, it can even be a place where policy is prepared, but it's
> not a place to store official documents.
>
>> * Anoth
Barry Warsaw writes:
> * "PMPT" policy
> http://python-modules.alioth.debian.org/
> git+ssh://git.debian.org/git/python-modules/tools/python-modules.git
Is policy.rst automatically kept in sync somehow in between
python-modules.git and http://python-modules.alioth.debian.org/?
--
Brian May
| diff --git a/policy.rst b/policy.rst
| index c09f03a..9a9abb4 100644
| --- a/policy.rst
| +++ b/policy.rst
| @@ -1,20 +1,19 @@
| -
| - Python Modules Packaging Team - Policy
| -
| +
[Ben Finney, 2015-10-19]
> So which of the following are redundant, and which names are canonical?
>
> * Debian Python Modules Team
> * Python Module Packaging Team
these two are the same thing
> * Debian Python Maintainers Team
this doesn't exist AFAIK
> For symmetry with “Python Application
Piotr Ożarowski writes:
> [Piotr Ożarowski, 2015-10-19]
> > DPMT and PAPT are two different things
>
> ups, PMPT != PAPT :)
So which of the following are redundant, and which names are canonical?
* Debian Python Modules Team
* Python Module Packaging Team
* Debian Python Maintainers Team
For s
[Piotr Ożarowski, 2015-10-19]
> DPMT and PAPT are two different things
ups, PMPT != PAPT :)
anyway, there are only documents each DPMT should know:
* https://www.debian.org/doc/packaging-manuals/python-policy/
* https://python-modules.alioth.debian.org/policy.html
everything else can help, but i
[Barry Warsaw, 2015-10-19]
> So we currently have several places where we have team policy described.
no.
Debian Python Policy¹ is something every single packages that extends
Python should follow. There are many teams (more than 4) each of them
can have their own policy that extends DPP.
Please
On October 19, 2015 1:31:37 PM EDT, Barry Warsaw wrote:
>So we currently have several places where we have team policy
>described.
>
>* The Debian wiki
> https://wiki.debian.org/Python and subpages
>
>* Another wiki page:
> https://wiki.debian.org/Teams/PythonModulesTeam
>
>* https://www.debia
Hi Jakub (2011.03.24_18:48:04_+0200)
> But you can claim that only if the package depends on the python2.X
> versions of all other modules it requires, even if some of them are
> arch:all! (The policy doesn't explain this...)
It does say:
| Packaged modules available for one particular version of
* Stefano Rivera , 2011-03-24, 15:35:
I see we still suggest ${python:Provides}. I was encouraged in
#debian-python to never use these unless there's an existing
dependency on a versioned package name.
Correctly using python Provides is expensive. Here's why:
“Provides: python2.X-eggs” is sup
Hi Scott (2011.03.24_15:45:36_+0200)
> I think once we get to pyhton2.7 as the only supported python, it
> won't matter.
As long as we handle rebuilds after every transition, it already
shouldn't matter (in Python 2 and 3). With dh_python2 we have the same
rebuild requirements, but don't suggest $
On Thursday, March 24, 2011 09:35:21 am Stefano Rivera wrote:
> I see we still suggest ${python:Provides}. I was encouraged in
> #debian-python to never use these unless there's an existing
> dependency on a versioned package name.
>
> There are no real packages using a name like python2.X-modulen
Hi Scott (2011.03.19_05:52:49_+0200)
> > What else needs doing?
I suggest making it clearer in the policy that byte-compilation etc.
are best taken care of by helpers. The policy *is* probably the first
place that someone looking to create a Python module/app package will
look.
There are a few pl
On Friday, March 18, 2011 10:23:05 pm Scott Kitterman wrote:
> Today's mail on XB-Python-Version motivates me to send out an overdue call
> for inputs on further changes to the Python policy. I know that needs to
> go.
>
> What else needs doing?
>
> Personally I'd like to concentrate on getting
Scott Kitterman ha scritto:
> doko uploaded the new policy in python-defaults, so we can consider this
> edition complete. Certainly it's not perfect and I'll be keeping an eye on
> bug submissions.
>
> I've also been added to uploaders for python-defaults and will continue to
> work on this.
On Mon, Dec 14, 2009 at 06:19, Scott Kitterman wrote:
> I know a lot of effort has been made to get the archive ready for Python 2.6.
> Either before or with the Python 2.6 upload, we are going to have to drop
> Python 2.4 as a supported Python version. Any work that could be done now to
> ease t
On Sun, Mar 08, 2009 at 09:35:38PM -0500, Steve M. Robbins wrote:
> WWW team: how does one go about getting
> http://www.debian.org/doc/packaging-manuals/python-policy/
> removed?
I suspect what's required is to
* modify the documentation build system to not publish this document
and then
Hi,
(I've opened a bug report against the Python Policy now, please Cc:
[EMAIL PROTECTED])
On Sun, Jul 23, 2006, Steve Langasek wrote:
> Are we talking about the case in which /usr/bin/python is still << 2.4, or
> are we talking about what such packages should do Coming Soon?
The poli
On Sun, Jul 23, 2006 at 07:08:52PM +0200, Loïc Minier wrote:
> Python Policy 3.2 states:
> 3.2 Programs Using a Particular Python Version
> """A program which requires a specific version of Python must begin with
> #!/usr/bin/pythonX.Y (or #!/usr/bin/env pythonX.Y). It must also
> specify a
Le jeudi 20 octobre 2005 à 09:04 -0500, Antal A. Buss a écrit :
> In installing time, the install script detect which version are
> installed (I.e. emacs and/or xemacs) and then compile the source for
> each version.
It's something that I've been wanting to implement and support in
dh_python for q
Antal A. Buss wrote:
> So, it's possible to install new modules to default, legacy and new version
> of Python, maintained only one package, using package dependency to know
> which Python version check.
> Specific modules are installed without check installed version
This is a good idea, if
- mo
Hi,
I don't know if it was already discussed.
If a (little) different approach is taken, such a (x)emacs or drscheme do.
In installing time, the install script detect which version are installed (I.e.
emacs and/or xemacs) and then compile the source for each version.
So, it's possible to insta
On Tue, 2005-10-18 at 08:23, Josselin Mouette wrote:
> Le mardi 18 octobre 2005 à 02:57 +0200, "Martin v. Löwis" a écrit :
> > Josselin Mouette wrote:
[...]
> But I'm not talking about python-gtk here, I'm talking about those
> hundreds of modules actually used by zero or one binary packages. Do we
Le mardi 18 octobre 2005 à 10:24 +0200, "Martin v. Löwis" a écrit :
> > Even in a situation like the current one, when we're stuck with 2.3 as
> > the default when there's 2.4 available, there are only a few python
> > packages which actually need the 2.4 version.
>
> What do you mean, "actually
To what cost? How many gigabytes of mirror space and bandwidth are we
wasting with python2.X-libprout stuff nobody ever uses?
I don't know. What is the answer to this question? I wouldn't expect
it to be more than 1GiB per mirror, though, likely much less. On
i386, for example, the "useless" pyt
Le mardi 18 octobre 2005 à 02:57 +0200, "Martin v. Löwis" a écrit :
> Josselin Mouette wrote:
> > Apart from a typo and the FSF address, the changes are about which
> > packaging variants are mandated, recommending to provide only one
> > python-foo package for each module, except when depending ap
Josselin Mouette wrote:
Apart from a typo and the FSF address, the changes are about which
packaging variants are mandated, recommending to provide only one
python-foo package for each module, except when depending applications
mandate another python version.
This way, we could enforce that poli
On Tue, 2005-10-11 at 20:29, Josselin Mouette wrote:
> Le lundi 10 octobre 2005 à 17:14 +0100, Donovan Baarda a écrit :
> > The best person to decide what packages need to support which old
> > versions of python are the package maintainers. They know this based on
> > the requests and bug reports
On Tue, 2005-10-11 at 20:23, Josselin Mouette wrote:
> Le lundi 10 octobre 2005 à 17:01 +0100, Donovan Baarda a écrit :
> > In 2.2.2, I would remove the "only" from "only supports python versions
> > different from the currrent default one"... You can use this for
> > packages that support the curr
Le lundi 10 octobre 2005 à 17:14 +0100, Donovan Baarda a écrit :
> The best person to decide what packages need to support which old
> versions of python are the package maintainers. They know this based on
> the requests and bug reports from the people that need them. It is up to
> them to balence
Le lundi 10 octobre 2005 à 17:01 +0100, Donovan Baarda a écrit :
> In 2.2.2, I would remove the "only" from "only supports python versions
> different from the currrent default one"... You can use this for
> packages that support the current default one as well as other versions.
The next section
On Sun, 2005-10-09 at 13:36, Josselin Mouette wrote:
> Le dimanche 09 octobre 2005 à 14:30 +0200, Matthias Klose a écrit :
[...]
> > I don't like the idea that maintainers of depending
> > applications have to "fight" with maintainers of library packages,
> > which versions they should provide.
>
On Sun, 2005-10-09 at 11:42, Josselin Mouette wrote:
> Hi list,
>
> prior to the upcoming python 2.4 transition, I've drafted some small
> changes we've already talked about on this list:
> http://people.debian.org/~joss/python/python-policy-draft.html/
>
> Apart from a typo and the FSF address,
Le dimanche 09 octobre 2005 à 14:30 +0200, Matthias Klose a écrit :
> Josselin Mouette writes:
> > Apart from a typo and the FSF address, the changes are about which
> > packaging variants are mandated, recommending to provide only one
> > python-foo package for each module, except when depending a
Josselin Mouette writes:
> Apart from a typo and the FSF address, the changes are about which
> packaging variants are mandated, recommending to provide only one
> python-foo package for each module, except when depending applications
> mandate another python version.
>
> This way, we could enforc
On su, 2003-08-24 at 08:38, Joe Wreschnig wrote:
> On Sat, 2003-08-23 at 23:54, Donovan Baarda wrote:
> > The problem is, run pydance as any user with write permissions to
> > /usr/share/games/pydance, and the *.py's there will be compiled and
> > saved as *.pyc's using whatever version of python w
On Sat, 2003-08-23 at 23:54, Donovan Baarda wrote:
> On Sun, 2003-08-24 at 09:38, Joe Wreschnig wrote:
> [...]
> > pydance comes with a number of "modules", which are actually its core
> > source code split into managable files. It installs these to
> > /usr/share/games/pydance, and doesn't byte co
On Sun, 2003-08-24 at 09:38, Joe Wreschnig wrote:
[...]
> pydance comes with a number of "modules", which are actually its core
> source code split into managable files. It installs these to
> /usr/share/games/pydance, and doesn't byte compile these. Based on my
> reading of this section, this is n
On Wed, 2003-08-20 at 07:09, Josselin Mouette wrote:
> In order to make it up to date, and to match current packaging
> practices, I have prepared a draft for a python policy update.
> It is available at: http://people.debian.org/~joss/python/
>
> It includes clarifications, a new section on bytec
Le ven 22/08/2003 à 04:37, Donovan Baarda a écrit :
> On Fri, 2003-08-22 at 05:05, Josselin Mouette wrote:
> > Le jeu 21/08/2003 à 04:24, Donovan Baarda a écrit :
> > > --- 1.4 Module Path, a question;
> > >
> > > Do we really want /usr/local/ on the python path before /usr/lib/? This
> > > make
On Fri, 2003-08-22 at 08:02, Josselin Mouette wrote:
> Le mer 20/08/2003 à 14:09, Josselin Mouette a écrit :
> > In order to make it up to date, and to match current packaging
> > practices, I have prepared a draft for a python policy update.
> > It is available at: http://people.debian.org/~joss/p
On Fri, 2003-08-22 at 05:05, Josselin Mouette wrote:
> Le jeu 21/08/2003 à 04:24, Donovan Baarda a écrit :
> > --- 1.4 Module Path, a question;
> >
> > Do we really want /usr/local/ on the python path before /usr/lib/? This
> > makes us vulnerable to busted local installs of python modules, in the
Le mer 20/08/2003 à 14:09, Josselin Mouette a écrit :
> In order to make it up to date, and to match current packaging
> practices, I have prepared a draft for a python policy update.
> It is available at: http://people.debian.org/~joss/python/
I have updated this draft using suggestions from firs
1 - 100 of 108 matches
Mail list logo
