On Thu, Mar 22, 2007 at 01:36:08PM +0100, Piotr Ożarowski wrote:
> [Tristan Seligmann, 22.03.2007]
> > * Pierre Habouzit <madcoder@debian.org> [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-<system> 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 not use $(pyversions -s) has many
chances to be buggy.
I believe pieces are sticking together nicely.
Oh and for your python2.5 only modules, a simple way to have a
painless binNMU _and_ backport friendly transition would be:
debian/control: Build-Depends: python-dev (>= 2.5) | python2.5-dev
debian/pyversions: 2.5- // or the equivalent XS-P-V: >= 2.5
debian/rules:
# pseudo code
if python2.5 is >= $(shell pyversions -d); then
PYTHON = python
else
PYTHON = python2.5
fi
# use $PYTHON everywhere in debian/rules
for now pyversions does not helps to write debian/rules, but I think
it should have a way to answer the question "does my asked
Python-Version also supports current", what he now does through current.
So _YEAH_ thanks to you, I know _where_ current is used for real. cute:
it's used to write the previous ! and indeed, you were correct to ask
for ">= 2.5, current" after all, if then in your debian/rules you did
sth like that:
PYTHON:=$(if $(shell pyversions -r),python,python2.5)
aaaaaaaall right, I think I get it all correctly now. Time to think
about something less confusing :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpC9B3eTZZoe.pgp
Description: PGP signature