Re: Proposed update to the python policy
[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 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. I wasn't in Mexico, I didn't write the policy but (I think) I still know the basics of the new policy. I'm maintaining pure Python modules [1], Python extensions [2], Python applications with public modules [3], Python applications with private modules [4] and I try to help other Debian Python Modules Team members. I just want to say that current tools are not perfect [5] to me and I think we could make them better (and I'm using both, though I prefer python-central for now; heck, I have even sent (accepted) patches to CDBS, but still prefer pure debhelper) [1] chardet, elixir, jinja, mako, paste, pastedeploy, pastescript, pastewebkit, pudge, pygments, routes, simplejson, sqlalchemy [2] pyenchant, pywavelets [3] gaupol [4] griffith, pypar2 [5] f.e. both systems are not handling old .pyc files (#385775, #409390) > > > 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. I'm just saying that there's no need to put "current" (better name would be "single") in XS-P-V but dh_tool should put it in *XB-P-V* when needed. I still think it's maintainer's job to specify (XS-P-V field) all compatible Python versions for the package. > 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). another example: when python2.3 was default and pytho2.4 "only" a supported one, I've packaged gaupol. Gaupol is Python application with public modules (i.e. it has files in "site-packages" directory) and it requires at least python2.4. All I needed to do was: * set Build-depends: to python-dev (>=2.4) | python2.4-dev * set XS-P-V to "current, >=2.4" and pycentral did change the hashbang and didn't compile modules for 2.3 (and I mean on user's machines as well as during the build time). Now I just want to be sure that pycentral will not compile it for python2.5 when it will be added to the supported Python-versions. Without "current" in XB-Python-Version I can't be sure of that. > > * 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. ok. I just thought it would be great if I could avoid another binNMU just to change hashbang when default Python version changes (to change, lets say "python2.4" to "python" - like I did with gaupol months ago) > > If the second, python-system can
Re: Proposed update to the python policy
[Steve Langasek, 22.03.2007] > On Thu, Mar 22, 2007 at 01:36:08PM +0100, Piotr Ożarowski wrote: > > 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 Build-Depends is used only at build time. Python-Versions field is in binary package. > - 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. so lets keep "current" in XS-P-V (and not only in XB-P-V) BTW: I'm building my python modules for *all* supported Python version at build time, even for arch:all packages - just to make sure they compile fine. > > > 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. if python-dev (>=2.X) | python2.X-dev is not available during build process, it will just fail and maintainer will not be able to upload such package, am I right? BTW: "current, >=2.4" helped me a lot with packaging gaupol when python2.3 was default -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgpEOkapNSqUL.pgp Description: PGP signature
Re: Proposed update to the python policy
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 > > 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 > Build-Depends is used only at build time. Python-Versions field is in binary > package. Sorry, what's your point? You seem to be repeating what I've said. > > > > 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. > if python-dev (>=2.X) | python2.X-dev is not available during build > process, it will just fail and maintainer will not be able to upload > such package, am I right? 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 it's built for "python"; if it's built for python2.X explicitly, the package name needs to reflect that, which means manual changes are needed to update it for a new python version. That's out of scope for 'current'. > BTW: "current, >=2.4" helped me a lot with packaging gaupol when > python2.3 was default Which is not an arch: any package, so is irrelevant to binNMU support. Oh, and if gaupol really needs python 2.4 or better, then the package's current dependencies are wrong... -- 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
[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/ 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 > > > Build-Depends is used only at build time. Python-Versions field is in binary > > package. > > Sorry, what's your point? You seem to be repeating what I've said. My point is Python-Version can contain "current" in XB-P-V even if it's not in XS-P-V. It was just an proposal (for people that don't like redundant data) > > > > > 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. > > > if python-dev (>=2.X) | python2.X-dev is not available during build > > process, it will just fail and maintainer will not be able to upload > > such package, am I right? > > 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 it's built for "python"; if it's built for python2.X explicitly, the > package name needs to reflect that, which means manual changes are needed to > update it for a new python version. That's out of scope for 'current'. when I write "current" I mean "single" (I didn't choose name for this keyword) If package is build for a single Python version and default Python version is not supported by this package, hashbang has to be set correctly and modules it provides (byte-)compiled (at build time *and* during the install/default python version change) > > BTW: "current, >=2.4" helped me a lot with packaging gaupol when > > python2.3 was default > > Which is not an arch: any package, so is irrelevant to binNMU support. 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 removed from Debian, package needed binNMU (due to wrong hashbang) even if it's arch:all. > Oh, and if gaupol really needs python 2.4 or better, then the package's > current dependencies are wrong... python2.4 is default now so there's no need to add extra dependencies -- -=[ Piotr Ozarowski ]=- -=[ http://www.ozarowski.pl ]=- pgphBsElVc2D9.pgp Description: PGP signature
Re: Proposed update to the python policy
On Fri, Mar 23, 2007 at 10:39:45AM +0100, Piotr Ożarowski wrote:
> [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/ 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
> >
> > > Build-Depends is used only at build time. Python-Versions field is in
> > > binary
> > > package.
> >
> > Sorry, what's your point? You seem to be repeating what I've said.
>
> My point is Python-Version can contain "current" in XB-P-V even if it's
> not in XS-P-V. It was just an proposal (for people that don't like
> redundant data)
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 what it really
meant because of that. It's more than confusing.
> > 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 it's built for "python"; if it's built for python2.X explicitly, the
> > package name needs to reflect that, which means manual changes are needed to
> > update it for a new python version. That's out of scope for 'current'.
>
> when I write "current" I mean "single" (I didn't choose name for this
> keyword)
>
> If package is build for a single Python version and default Python
> version is not supported by this package, hashbang has to be set
> correctly and modules it provides (byte-)compiled (at build time *and*
> during the install/default python version change)
IMHO that's better suited to say that to the dh_tool. Like a :
dh_py{support,central} --single-version
That would indeed flag the package in the Packages accordingly (but
XB-P-V is not the place IMHO).
But yes, this information really has to "leak" somehow as the RM needs
it.
As of your python-dev (>> 2.5) | python2.5-dev be warned that it does
not works for an arch:any package: sbuild always take the first
alternative, so an arch:any package won't build with that hack. It only
works for arch:all packages as pbuilder/debuild/...whatever are more
clever about that.
So there is no way to deal with packages that only support "future"
python versions yet. Though I expect it to concern only a few packages
that will need a sourcefull upload to migrate to a scheme where they
support the policy.
Your B-D + XS-P-V hack only works with brittle side effects, and for
arch:all packages, that are not subject to binNMUs anyway (at least not
untill we have arch:all buildd's).
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpomRVOLK4RV.pgp
Description: PGP signature
Re: corner abalone
We told you watch NNYR Yesterday +25% in 1 day It.s only just begun Northamerican Energy Group Corp. Symbol : NNYR 5 day Expected : $0.50 ( 500% profit ) Get in tomorrow or get left out!! This is going to double in next 2 days Real Comp with Real Products Get in tomorrow or be left out!! got 25 points from Leandro Barbosa , never led in this one and fell behind by confidence booster for us,'' Anthony said. ''To beat a team like that. You know ways. But at Michigan, we have a tradition of winning Big Ten and national ,000 to ex-Wolverines Chris Webber, Maurice Taylor, Robert Traylor and coach on March 31, 2011, to earn a deferred-compensation package after the school's came together for them. Anthony drew the foul and some of the loudest cheers annual contributions of ,000. By firing him, the school keeps the invested money, The Wolverines finished 22-13, with an 87-66 loss at Florida State on Thursday night. D'Antoni said. ''We're in a little bit of a funk right now. Discombobulated. We their fourth straight win, a 131-107 blowout of the Phoenix Suns on Saturday - Original Message - From: "Sethy Krauseu" <[EMAIL PROTECTED]> To: Sent: Thursday, March 22, 2007 8:27 PM Subject: corner abalone Experience a Charging Bull North american Energy Group C o r p SYmb-N_N_Y_R Cannot go wrong at 8 cents Expected : .70 ( 1000 percent return!! ) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Proposed update to the python policy
[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 what it really
> meant because of that. It's more than confusing.
OK
X?-Python-Version: informations about supported Python versions ("2.3-", ">2.3",
">=2.4, <=2.7", etc.)
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
> IMHO that's better suited to say that to the dh_tool. Like a :
>
> dh_py{support,central} --single-version
another solution and it looks good as well. If it will set package type
correctly
so that python-system (the one installed on target machine, not the one
installed
on build machine) will byte-compile only for Python versions I want, then it's
OK
with me. I'm able to control Python versions used during build time, if
I will be able to control it on target machine as well (through
XB-Python-Version and XB-Python-Type) than it's all what I want.
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpY06Th5wtXg.pgp
Description: PGP signature
Re: Proposed update to the python policy
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 done inside debian/rules? -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `-our own. Resistance is futile.
Re: Proposed update to the python policy
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 good to me > > And how do you ensure that this matches what's actually done inside > debian/rules? XB is a binary package header. It's up to the dh_tool responsibility to check that if the maintainer puts "single" and that there is multiple python obviously supported it's wrong, and it should make the package FTBFS. Obviously, the problem is harder when only one python version is supported at the time, as you cannot made the difference between the two. That's why I've not done any proposal yet, because the problem does not look obvious in the first glance. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp4HR7FdPPua.pgp Description: PGP signature
Re: Proposed update to the python policy
[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 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 done inside
> > debian/rules?
and how do we do this now? It works fine with python-central (it just
adds "current" to the XB-P-V)
> XB is a binary package header. It's up to the dh_tool responsibility
> to check that if the maintainer puts "single" and that there is multiple
> python obviously supported it's wrong, and it should make the package
> FTBFS.
FTBFS? Why? No mater for how many Python versions you build your module in
debian/rules, only one set of .py files is installed (in
/usr/share/python-support/ or /usr/share/pycentral/) - that doesn't
apply to .so files, but why should the build process fail? If more than
one .so file is build, only the right one should be installed.
Maintainer have to know what "single" means and why he wants it. It
should not be used with "normal" Python modules (i.e. python-*
packages). If this field is not set, "multiple" should be assumed.
I think it can be detected automatically (f.e. by using mentioned
python-dev vs. python-all-dev dependency or "dh_tool --single-version")
but if you think it's confusing, then setting it by hand shouldn't be a
big problem.
> Obviously, the problem is harder when only one python version is
> supported at the time, as you cannot made the difference between the
> two.
Sorry, I don't see a problem here. This field cannot be set only by
checking for how many Python versions module was build at the build
time.
> That's why I've not done any proposal yet, because the problem does
> not look obvious in the first glance.
I know that it could be hard to understand me (I blame my English skills)
but I think you all understand the problem now and "current" will not
be removed from the policy. My packages are safe for now ;-)
BTW: I was using "XS-Python-Version: 2.4" when "current, >=X.Y" was not
supported. That really wasn't "New policy"-like.
PS I thought it's time to think about merging py{central,support} but I
guess this discussion will end on "current" keyword.
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgplgIbybbtBO.pgp
Description: PGP signature
Re: Proposed update to the python policy
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 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 done inside
> > > debian/rules?
>
> and how do we do this now? It works fine with python-central (it just
> adds "current" to the XB-P-V)
>
> > XB is a binary package header. It's up to the dh_tool responsibility
> > to check that if the maintainer puts "single" and that there is multiple
> > python obviously supported it's wrong, and it should make the package
> > FTBFS.
>
> FTBFS? Why? No mater for how many Python versions you build your module in
> debian/rules, only one set of .py files is installed (in
> /usr/share/python-support/ or /usr/share/pycentral/) - that doesn't
> apply to .so files, but why should the build process fail? If more than
> one .so file is build, only the right one should be installed.
>
> Maintainer have to know what "single" means and why he wants it. It
> should not be used with "normal" Python modules (i.e. python-*
> packages). If this field is not set, "multiple" should be assumed.
>
> I think it can be detected automatically (f.e. by using mentioned
> python-dev vs. python-all-dev dependency or "dh_tool --single-version")
> but if you think it's confusing, then setting it by hand shouldn't be a
> big problem.
>
> > Obviously, the problem is harder when only one python version is
> > supported at the time, as you cannot made the difference between the
> > two.
>
> Sorry, I don't see a problem here. This field cannot be set only by
> checking for how many Python versions module was build at the build
> time.
My point was: if the maintainer asks for a "single" packaging way, and
that the dh_tool finds a "multiple" package or the reverse, it should
complain, loudly. When it detects any kind of inconsistency in fact.
Here was what I tried to explain. Basically we just agree.
> > That's why I've not done any proposal yet, because the problem does
> > not look obvious in the first glance.
>
> I know that it could be hard to understand me (I blame my English skills)
> but I think you all understand the problem now and "current" will not
> be removed from the policy. My packages are safe for now ;-)
Oh I think "current" will be removed from the policy as it is now.
Having it X?-PV is very confusing. THe current from pycentral can
remains where it is in XS-PV but that's an implementation detail from
pycentral, and won't be normative IMHO.
> PS I thought it's time to think about merging py{central,support} but I
> guess this discussion will end on "current" keyword.
No this discussion is about driving the remaining grey areas of the
policy from the needs that the policy has to fulfill rather than the
implementation details of the py* tools, which has been made for too
long.
Current was a big point of disagreement in the past, hence it has been
central in that discussion. It does not mean that we've forgotten the
rest :)
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgp2u1e87jznT.pgp
Description: PGP signature
