Le mar 22 août 2006 01:00, Josselin Mouette a écrit :
> > > * -V is a redundant interface, since it does something
> > > approximating what debian/pyversons does. So things should be
> > > able to switch to the other interface, except in edge cases
> > > (although IMHO it's not an appropriate interface for a debhelper
> > > program), and for the edge cases, -V could be added to the other
> > > two programs.
> >
> > Exactly, we should get rid of the "-V" parameter completely.
>
> I strongly disagree here. The -V flag achieves something very
> specific (e.g. for Zope packages) and there is no way that we can get
> rid of it (or another interface achieving similar functionality). See
> #381389 for an explanation.
-V may also be used for packages that are not in the scope of the
policy: meaning applications that do not support current python /yet/.
For those, you need to build-dep upon pythonX.Y-dev (X.Y >> current)
and to dh_pysupport -VX.Y.
when that application will support current (e.g. because X.Y becomes
current) the packaging has to be changed to use python-dev as a B-D and
remove the -VX.Y call.
and even with a more clever dh_pysupport (and I don't think that's
doable without bloating the script) you won't spare the B-D change
anyway, so it won't spare the new sourceful upload.
(the same is true for applications that do not support current python
*anymore*, e.g. applications that only work with python2.3 nowadays, if
that exists).
the policy deals with package that support current (and to some extent,
for pure python modules where the python (>= X.Y) | pythonX.Y
dependency kludge allow a more smooth upgrades[1]). Everything else is
on its own, and there -V *is* a way to help packaging those
applications. Except for the pure modules, when you package a "thing"
for a specific non-current python version, you should build-depend on
pythonX.Y-dev[2].
[1] I repeat this is a kludge, and only appliable to pure python
modules. Given that there is quite a couple of them, it's a useful
kludge though.
[2] build-depending on python-all-dev is horrible as a general rule, if
you build against a sole python version. Though, even for
applications, there is cases where you can kludge the debian/rules
to switch from a pythonX.Y only build to a /usr/bin/python one,
using things like:
* B-D on p-all-dev
* building with a magic substitutions of $(shell pyversions -d)
by "python" in the requested list of pyversions, so that when the
X.Y you depend upon, you magically switch to a package built for
current. Though, I really think such packaging methods are
harmful, and that the python2.4-that-is-out-since-years should
not happen again thanks to the new policy, so that we can assume
that only *few* packages will not support the current version.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpik9e4J9VvY.pgp
Description: PGP signature