Re: Proposed update to the python policy

[Steve Langasek]

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 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 python-dev (>= 2.5) | 
> > > > python2.5-dev
> > > > and set XS-Python-Version: to "current, >=2.5"

> > > > example packages: emma, pypar2, gaupol, griffith

> > >   could you explain me in which part 'current' is helping you here ? I
> > > missed to understand what asking for:

> > >   XS-Python-Version: >= 2.5

> > Doesn't this indicate that the package should be built for all versions
> > 2.5 and up, rather than a single version?

> yes, but since package is depending only on python-dev (and not 
> python-all-dev),
> python- should assume "current" by default (and add it to 
> XB-Python-Version
> so that there will be no problems with recompilation of pyc files when 2.6
> will become default)

hmm, three things:

- 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
  follow the new policy but obviously still need to b-d on python-*dev.
- Build-Depends information is only in the Sources file, not in Packages;
  detecting packages that need binNMUs requires trawling the Packages file,
  it would be nice if it didn't require correlating both Packages and
  Sources
- having a package's build rules behavior vary in response to the contents
  of the build-depends is unprecedented and, IMHO, a very bad idea.
  Basically, this would eliminate a very important check that the maintainer
  hasn't made a mistake along the line -- it's far better to get a build
  failure in such a case than to get a misbuilt package.

> > As I understood it, "current" indicates that the package should only be
> > built for one version of python, the version that is currently the
> > default version in Debian.

> not necessary default (see "current, >=2.X" where 2.X is greater than default)
> but for single version only, yes. I understand it this way, but
> apparently I don't understand "current", though.

I don't think it was intended that "current, >= 2.X" be used to
*successfully* build packages when 2.X is greater than the currently
available python-dev.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
[EMAIL PROTECTED]   http://www.debian.org/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed update to the python policy

[Pierre Habouzit]

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 was previously built. This is a hint for the release
> > > > managers (to know which packages need a binNMU), and could be the base
> > > > for a script automating the build process.
> > > 
> > >   It's not necessarily true: when there is only one python supported,
> > > you can't tell the difference between a package that only supports the
> > > default python, or any of them :)
> > 
> > This is not a problem for the dh_ tool, as the resulting binary package
> > will be exactly the same in both cases.
> 
> simplejson package is build only for python2.4, because only this version

  That's a pure python module, that scope of the policy is well
understood, and works without anybody's help thanks to the dh_tools.
There is no human help needed for that, at all.

> > This is indeed a problem for the release managers, as they need a way to
> > disambiguate between these two cases. In this case, "current" is a hint,
> > a declaration that has to be matched by what's in debian/rules, but it's
> > not a proof the package is built this way.
> > 
> > If we really need such a hint, I'd prefer to see it in another place
> > than the field containing version information. However we might as well
> > use the python-dev / python-all-dev build-dependencies to obtain the
> > same information.
> 
> python-dev / python-all-dev issue should be (IMHO, of course) used just
> at the build time to set Python-Version correctly. python-system should
> not depend on informations from source packages (it simply doesn't have
> access to them). Python-Version (or whatever we will call it) should
> contain informations about:
> 
> * which Python versions this package can work with

  that's not doable. The PV field or its equivalent debian/pyversions
has to be filled. There is no way for the build system to know if this
or that extension is compatible with this or that python version. This
is a declaration that the maintainer has to do.

  This information is only useful for the dh_tool though, so I don't see
the need to make it mandatory. It's up to the maintainer to choose what
fits his needs. What has to be mandatory is the annotations that other
python packages needs (the Python-Provides proposal), and what the RM
need (and here PV is only part of the things the RM need).

> * is this package meant to be compiled for all allowed Python versions or
>   just for a single (default or nearest available) version

> * and maybe: does this package has a shebang to handle
  that is the maintainer's job and maybe the dh_tool one to deal with
that.

> If the second, python-system can check [1] if it can/should change shebangs
> automatically (if package is arch:all and default Python version meets
> requirements)

  No he should not. At least not automatically. In fact, when the
package is pure python, that already works automatically.

  I don't really think you grasp the issues we were discussing. The
"issues" you raise are already dealt with and correctly understood.
Though the policy is really badly written if it wasn't already obvious
to you (and I do thing it is, badly written I mean).

> > I don't think we are missing any case, but we should probably write some
> > binNMU detection script for use by the release managers, summarizing all
> > of these thoughts.
> 
> It should be really easy if all Python-related packages will have
> Python-Version field.

  No, honnestly I don't think you get it correctly, but I may be
mistaken. Though I think one of my mail already explains the whole thing
pretty clearly.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpBj7mUZN9zG.pgp
Description: PGP signature

Re: Proposed update to the python policy

[Piotr Ożarowski]

[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 was previously built. This is a hint for the release
> > > managers (to know which packages need a binNMU), and could be the base
> > > for a script automating the build process.
> > 
> >   It's not necessarily true: when there is only one python supported,
> > you can't tell the difference between a package that only supports the
> > default python, or any of them :)
> 
> This is not a problem for the dh_ tool, as the resulting binary package
> will be exactly the same in both cases.

simplejson package is build only for python2.4, because only this version
is fully supported in Debian now. I (as a package maintainer) want it to be
(byte-)compiled for all supported Python versions. It's arch:all so when
new (2.5, 2.6, ...) Python version will be added to the supported ones or user
will install unsupported Python version (that still matches versions specified
in package's Python-Version header) I want python- to byte-compile it
for all installed Python versions that my package can work with.

I think it's dh_tool task to set Python-Version field correctly (by
parsing build dependencies and XS-P-V / pyversions) so that
python- and RMs will not have problems with telling (grep-dctrl):

* which packages will need binNMU when list of supported Python version
  will change (public python extensions)
* which packages will need binNMU when default Python version will
  change (shebang issue, private python extensions)
* which packages will only need byte-compilation for newly added Python
  versions (or removal of old .pyc files)
* which packages will only need recompilation of .pyc files (private modules,
  public modules used only by Python applications ["current" keyword])

If dh_tool will set Python-Version header in binary package and it's
(Python-Version's) content will be standardised as well as the location
where python- should look for .py/.so files, I think we can just
set Depend: to python-system where python-system is provided by
python-central or python-support (no need to install both systems)

> This is indeed a problem for the release managers, as they need a way to
> disambiguate between these two cases. In this case, "current" is a hint,
> a declaration that has to be matched by what's in debian/rules, but it's
> not a proof the package is built this way.
> 
> If we really need such a hint, I'd prefer to see it in another place
> than the field containing version information. However we might as well
> use the python-dev / python-all-dev build-dependencies to obtain the
> same information.

python-dev / python-all-dev issue should be (IMHO, of course) used just
at the build time to set Python-Version correctly. python-system should
not depend on informations from source packages (it simply doesn't have
access to them). Python-Version (or whatever we will call it) should
contain informations about:

* which Python versions this package can work with
* is this package meant to be compiled for all allowed Python versions or
  just for a single (default or nearest available) version
* and maybe: does this package has a shebang to handle

If the second, python-system can check [1] if it can/should change shebangs
automatically (if package is arch:all and default Python version meets
requirements)

[1] at user's machine (when new version of "python" package will be
installed)

> I don't think we are missing any case, but we should probably write some
> binNMU detection script for use by the release managers, summarizing all
> of these thoughts.

It should be really easy if all Python-related packages will have
Python-Version field.

-- 
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-


pgpcG4pKkUDFa.pgp
Description: PGP signature

Re: Proposed update to the python policy

[Josselin Mouette]

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 was previously built. This is a hint for the release
> > managers (to know which packages need a binNMU), and could be the base
> > for a script automating the build process.
> 
>   It's not necessarily true: when there is only one python supported,
> you can't tell the difference between a package that only supports the
> default python, or any of them :)

This is not a problem for the dh_ tool, as the resulting binary package
will be exactly the same in both cases.

This is indeed a problem for the release managers, as they need a way to
disambiguate between these two cases. In this case, "current" is a hint,
a declaration that has to be matched by what's in debian/rules, but it's
not a proof the package is built this way.

If we really need such a hint, I'd prefer to see it in another place
than the field containing version information. However we might as well
use the python-dev / python-all-dev build-dependencies to obtain the
same information.

I don't think we are missing any case, but we should probably write some
binNMU detection script for use by the release managers, summarizing all
of these thoughts.
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Proposed update to the python policy

[Pierre Habouzit]

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, python-(all-?)-dev is a already here to give a
> > hint to the dh_tool about your intention. Excellent point.
> 
> Just nitpicking: the dh_ tool doesn't need to know that, as it can guess
> it from what was previously built. This is a hint for the release
> managers (to know which packages need a binNMU), and could be the base
> for a script automating the build process.

  It's not necessarily true: when there is only one python supported,
you can't tell the difference between a package that only supports the
default python, or any of them :)

  And the maintainer can change his mind too, so looking in the past
packages looks brittle.


-- 
·O·  Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org


pgpKEDkdGHW2O.pgp
Description: PGP signature

Re: Proposed update to the python policy

[Josselin Mouette]

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 about your intention. Excellent point.

Just nitpicking: the dh_ tool doesn't need to know that, as it can guess
it from what was previously built. This is a hint for the release
managers (to know which packages need a binNMU), and could be the base
for a script automating the build process.

-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée

Re: Bug#415844: ITP: python-fpconst -- Utilities for handling IEEE 754 floating point special values

[Stefano Zacchiroli]

On Thu, Mar 22, 2007 at 05:30:54PM +0100, Bernd Zeimetz wrote:
> > See http://lists.debian.org/debian-python/2007/03/msg00042.html.
> He had replied to me within a few days, I missed to post it to d-py, though.

Here it is:

  http://lists.debian.org/debian-python/2006/07/msg00022.html

Hi discussed the issue with Raphael on IRC (#debian-python on freenode),
he had the intention (after sending that message) of hijacking the
package but missed the time. So I took over the task.

I actually made a mistake by not trying to ping Ed again, but I think
(and you confirmed that) that's its fine for him for someone else to
take over the maintenance given that soappy was NMUed for the last 3
years or so.

> > My python-soappy package is ready and you can find the current version
> not a problem at all, all I did was to get the last NMUs ready and done.

Have a look at the changelog for my changes, some of them (like my
handling of fpconst.py) will probably go away with your python-fpconst
package. Here is a direct link to the changelog:

  
http://svn.debian.org/wsvn/python-modules/packages/python-soappy/trunk/debian/changelog?op=file&rev=0&sc=0

> If it's ok with you I'll fpconst and edit your packaging in svn
> accordingly.

Totally fine, feel free to add yourself to the Uploaders: field.

> I need to get an account on Alioth first, though.  Depending on how
> long that will take I'll probably just mail you a patch

Usually is quite fast. After you get the account just go to the
python-modules project and fill a request for being added to the
project, that's usually a quick step too.

Thanks for your efforts.
Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Bug#415844: ITP: python-fpconst -- Utilities for handling IEEE 754 floating point special values

[Bernd Zeimetz]

Heya,
>
> Just these days I've hijacked the python-soappy package, with the
> agreement of the python-modules team since Ed did not reply to their
> ping a long time ago.
>
> See http://lists.debian.org/debian-python/2007/03/msg00042.html.
>   
He had replied to me within a few days, I missed to post it to d-py, though.

> My python-soappy package is ready and you can find the current version
> in the svn repository of the alioth project 'python-modules'. I was
> going to upload in a few days.
>
> Please do not fork the effort.
>   
not a problem at all, all I did was to get the last NMUs ready and done.
> What about you packaging fpconst and integrate the needed changes in my
> starting version of a new python-soappy package?
>   
If it's ok with you I'll fpconst and edit your packaging in svn accordingly. I 
need to get an account on Alioth first, though. Depending on how long that will 
take I'll probably just mail you a patch

Cheers,

-- 
Bernd Zeimetz
<[EMAIL PROTECTED]> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Bug#415844: ITP: python-fpconst -- Utilities for handling IEEE 754 floating point special values

[Stefano Zacchiroli]

On Thu, Mar 22, 2007 at 04:20:01PM +0100, Bernd Zeimetz wrote:
> The fpconst module is packaged within the python-soappy package at the
> moment, which I have adopted with Ed Boraas' agreement. There're a few
> reasons to package the small module as an extra package:

Aaarrrggghhh!

Just these days I've hijacked the python-soappy package, with the
agreement of the python-modules team since Ed did not reply to their
ping a long time ago.

See http://lists.debian.org/debian-python/2007/03/msg00042.html.

My python-soappy package is ready and you can find the current version
in the svn repository of the alioth project 'python-modules'. I was
going to upload in a few days.

Please do not fork the effort.

I would be glad of course to have you as an additional upload of the
package and I have no objection in forking the fpconst.py module. In
fact that would also simplify the packaging of soappy.

What about you packaging fpconst and integrate the needed changes in my
starting version of a new python-soappy package?

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
[EMAIL PROTECTED],debian.org,bononia.it} -%- http://www.bononia.it/zack/
(15:56:48)  Zack: e la demo dema ?/\All one has to do is hit the
(15:57:15)  Bac: no, la demo scema\/right keys at the right time


signature.asc
Description: Digital signature

Re: Proposed update to the python policy

[Pierre Habouzit]

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 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 python-dev (>= 2.5) | 
> > > > python2.5-dev
> > > > and set XS-Python-Version: to "current, >=2.5"
> > > > 
> > > > example packages: emma, pypar2, gaupol, griffith
> > > 
> > >   could you explain me in which part 'current' is helping you here ? I
> > > missed to understand what asking for:
> > > 
> > >   XS-Python-Version: >= 2.5
> > 
> > Doesn't this indicate that the package should be built for all versions
> > 2.5 and up, rather than a single version?
> 
> yes, but since package is depending only on python-dev (and not 
> python-all-dev),
> python- should assume "current" by default (and add it to 
> XB-Python-Version
> so that there will be no problems with recompilation of pyc files when 2.6
> will become default)

  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 about your intention. Excellent point.


> > >   and please tell me what it changed in the package you built with that.
> > > I'm curious. Btw I don't think you answered the question properly, as
> > > you didn't explained the think current achieves for you. And honnestly,
> > > it's not a trick question, I mean it, what is its purpose for you. I
> > > don't see its usefulness, but I may miss a thing :)
> > 
> > As I understood it, "current" indicates that the package should only be
> > built for one version of python, the version that is currently the
> > default version in Debian.
> 
> not necessary default (see "current, >=2.X" where 2.X is greater than default)
> but for single version only, yes. I understand it this way, but
> apparently I don't understand "current", though.
> 
> I think compiling (private or not) modules provided by 
> {emma,gaupol,grifffith,any
> other Python application} for all supported Python versions is just a
> waste of space.

  For private modules, it's not possible to compile _or_ byte-compile it
for many python versions, because a private module lives in a non
versionned directory, hence you can't have it built for two python
version at a time. There is two cases though:
  * either it's a pure python private module, and afaict, the case is
handled by dh_py* tools correctly, and nothing is needed from the
maintainer side.
  * or it's a binary module, and then binNMU is mandatory.


  When it's a public module, then well, I agree with Steve, it depends
on the popularity of the package. See zope e.g., it's always a python
version behind for many reasons, and people programming for zope will
want to be able to use any popular python module around. Not building
your module for them is a bad idea, so again here the case is twofold:
  * either it's a pure python public module, and then, dh_py* tools will
handle an optimal byte compilation by themselves. Let them work like
that, it's exactly what is needed: if byte compiles only for python
versions that are installed on the user machine. There is absolutely
no waste here.
  * either it's a binary module, and yes, then it has to be built by the
buildd, hence we can have some sort of waste, and the "do you have a
lot of rdepends or not" is the criterion to know if you should
provide modules for every supported version, or only default.

  Just consider that when you are built for many python at the same
time, you ease the python default change a lot.

  So there is pros and cons, and I now (with Steves remarks) believe
that this choice is indeed up to the maintainer. So as a matter of a
conclusion, we just need a way to make "us" aware that the maintainer
chosed one or the other.

  I like your python-dev vs. python-all-dev remark, I really believe the
dh_py* helpers can use that when there is public binary modules involved
to know what the maintainer decided. For private modules, the task is
easy, and I know dh_pysupport knows how to detect them already, it would
just have to flag them in the Packages.gz somehow in order to help the
RMs.


  Of course, that still leaves one corner case:
  * there is only one python version supported (current scenario btw, we
only have python2.4) ;
  * the package B-D upon python-all-dev ;
  * the maintainer only builds for default.

  This is the sole case when the dh_py* tools cannot verify if the
maintainer did correct stuff, but that's definitely a bug in the
package. Moreover we can add a lintian check for that: a package that
build-dep onto python-all-dev and do

Re: Proposed update to the python policy

[Piotr Ożarowski]

[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. will work only with
> > > python2.5 and above, I can Build-depend on python-dev (>= 2.5) | 
> > > python2.5-dev
> > > and set XS-Python-Version: to "current, >=2.5"
> > > 
> > > example packages: emma, pypar2, gaupol, griffith
> > 
> >   could you explain me in which part 'current' is helping you here ? I
> > missed to understand what asking for:
> > 
> >   XS-Python-Version: >= 2.5
> 
> Doesn't this indicate that the package should be built for all versions
> 2.5 and up, rather than a single version?

yes, but since package is depending only on python-dev (and not python-all-dev),
python- should assume "current" by default (and add it to 
XB-Python-Version
so that there will be no problems with recompilation of pyc files when 2.6
will become default)

> >   and please tell me what it changed in the package you built with that.
> > I'm curious. Btw I don't think you answered the question properly, as
> > you didn't explained the think current achieves for you. And honnestly,
> > it's not a trick question, I mean it, what is its purpose for you. I
> > don't see its usefulness, but I may miss a thing :)
> 
> As I understood it, "current" indicates that the package should only be
> built for one version of python, the version that is currently the
> default version in Debian.

not necessary default (see "current, >=2.X" where 2.X is greater than default)
but for single version only, yes. I understand it this way, but
apparently I don't understand "current", though.

I think compiling (private or not) modules provided by 
{emma,gaupol,grifffith,any
other Python application} for all supported Python versions is just a
waste of space.

-- 
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-


pgpPq44hl27Vi.pgp
Description: PGP signature

Re: Proposed update to the python policy

[Tristan Seligmann]

* 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 above, I can Build-depend on python-dev (>= 2.5) | 
> > python2.5-dev
> > and set XS-Python-Version: to "current, >=2.5"
> > 
> > example packages: emma, pypar2, gaupol, griffith
> 
>   could you explain me in which part 'current' is helping you here ? I
> missed to understand what asking for:
> 
>   XS-Python-Version: >= 2.5

Doesn't this indicate that the package should be built for all versions
2.5 and up, rather than a single version?

>   and please tell me what it changed in the package you built with that.
> I'm curious. Btw I don't think you answered the question properly, as
> you didn't explained the think current achieves for you. And honnestly,
> it's not a trick question, I mean it, what is its purpose for you. I
> don't see its usefulness, but I may miss a thing :)

As I understood it, "current" indicates that the package should only be
built for one version of python, the version that is currently the
default version in Debian.
-- 
mithrandi, i Ainil en-Balandor, a faer Ambar


signature.asc
Description: Digital signature

Re: Proposed update to the python policy

[Mikhail Gusarov]

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 tools
and to policy. Not everyone can attend the conferences.

-- 
JID: [EMAIL PROTECTED]


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Re: Proposed update to the python policy

[Josselin Mouette]

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 build. The dh_pysupport script is a drop-in
replacement for the old dh_python (except for the multiple python2.X-foo
binary case), and will work whatever versions are built.

I'm not aware of any use case that python-support can't currently
handle. If you find one, please file a bug report.
-- 
 .''`.
: :' :  We are debian.org. Lower your prices, surrender your code.
`. `'   We will add your hardware and software distinctiveness to
  `-our own. Resistance is futile.


signature.asc
Description: Ceci est une partie de message	numériquement signée