[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 ]=-
Attachment:
pgpGHPWfpEyj4.pgp
Description: PGP signature