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 madcoder@debian.org
OOO http://www.madism.org
Attachment:
pgpDrCciQo5nZ.pgp
Description: PGP signature