On Tue, May 01, 2007 at 12:17:33AM +0100, Floris Bruynooghe wrote:
Hi
On Wed, Mar 28, 2007 at 08:39:42PM +0200, Pierre Habouzit wrote:
wrt the current thingie, I may have a proposal ready soon, I just
need to polish the details, and look how hard it would be to upgrade
the dh_py* tools
Hi
On Wed, Mar 28, 2007 at 08:39:42PM +0200, Pierre Habouzit wrote:
wrt the current thingie, I may have a proposal ready soon, I just
need to polish the details, and look how hard it would be to upgrade
the dh_py* tools to them. Well, I've a hard week of paid work ahead, so
I don't expect
While the discussion is still ongoing about the current keyword, it
seems that everyone agrees with the other changes which are only loosely
related. Can we proceed with these, until we agree on how current
should be replaced?
--
.''`.
: :' : We are debian.org. Lower your prices, surrender
[Josselin Mouette, 28.03.2007]
While the discussion is still ongoing about the current keyword, it
seems that everyone agrees with the other changes which are only loosely
related. Can we proceed with these, until we agree on how current
should be replaced?
IMHO, yes
--
-=[ Piotr
On Fri, Mar 23, 2007 at 10:39:45AM +0100, Piotr Ożarowski wrote:
Ugh, it should fail *regardless* of the existence of python2.X-dev. Why
would you ever call it current if it's building for something that *isn't*
the current version of python? A package should only be called python-foo
if
[Steve Langasek, 24.03.2007]
On Fri, Mar 23, 2007 at 10:39:45AM +0100, Piotr Ożarowski wrote:
I couldn't set python in hashbang (as I said before: gaupol will not work
with python2.3). Package was build when python2.3 was default so
hashbang was set to python2.4. Now when python2.3 was
[Pierre Habouzit, 22.03.2007]
On Thu, Mar 22, 2007 at 10:13:40PM +0100, Piotr Ożarowski wrote:
[Josselin Mouette, 22.03.2007]
Le jeudi 22 mars 2007 à 19:56 +0100, Pierre Habouzit a écrit :
Just nitpicking: the dh_ tool doesn't need to know that, as it can
guess
it from what
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/ binNMUable, from those that don't
[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
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 with
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
Le mercredi 21 mars 2007 à 15:51 -0700, Steve Langasek a écrit :
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, allowing binNMUable transitions, and generally
simplifying the
On Thu, Mar 22, 2007 at 12:05:30AM +0100, Pierre Habouzit wrote:
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
[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,
On Wed, Mar 21, 2007 at 04:50:30PM -0700, Steve Langasek wrote:
On Thu, Mar 22, 2007 at 12:05:30AM +0100, Pierre Habouzit wrote:
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
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
On Thu, Mar 22, 2007 at 01:17:17AM +0100, Pierre Habouzit wrote:
In the original proposal, 'current' was the flag to tell the packaging tools
that pyversions -d *should* be used. There is of course nothing that stops
a maintainer from invoking pyversions -d manually;
Okay I see. As a
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
48 matches
Mail list logo
