[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 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.
At build time, yes. I was talking about runtime.
> 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 know 90% of what I wrote is already implemented in pycentral *or*
pysupport. I just wanted to say what I want from python-system before it
could be provided by python-{central,support} (I want them to be merged
at some time).
> > > 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.
If Python-Version will have all data I mentioned in my previous mail
(and Python-Version is a field in *binary* package generated
automatically from XS-P-V and Build dependencies during the build
process), I still think it would be easy to detect all packages that
need binNMU.
--
-=[ Piotr Ozarowski ]=-
-=[ http://www.ozarowski.pl ]=-
pgpsYTEoe4UHY.pgp
Description: PGP signature
