[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Updated dh_python to satisfy everybody



On Tue, 2006-06-20 at 07:27 +0200, Andreas Barth wrote:
> * Joe Wreschnig (piman@sacredchao.net) [060620 07:14]:
> > On Tue, 2006-06-20 at 06:49 +0200, Andreas Barth wrote:
> > > * Raphael Hertzog (hertzog@debian.org) [060620 01:35]:
> > > > On Mon, 19 Jun 2006, Raphael Hertzog wrote:
> > > > >      - uses "XS-Python-Standards-Version: 0.4" as reference field to run in new
> > > > >        policy mode. The presence of XS-Python-Version will also trigger the new
> > > > >        policy mode (this is for short-term compatibility, it may be removed in
> > > > >        the not too-distant future).
> > > > 
> > > > Joe proposed on IRC to use "debian/pycompat" instead of a new field. It
> > > > sounds very much debhelper-ish and I like it.
> > > 
> > > It depends what the field means.
> > > 
> > > For me, the Standards-Version was mainly a marker to say "this package
> > > is compatible to Version x.y of the policy" - which allows not only
> > > debhelper to work on it, but also to search for old packages etc. This
> > > is incompatbile with debian/pycompat (at least, if you want to do it
> > > efficient).
> > 
> > debhelper does not use Standards-Version for this purpose. It doesn't
> > use it at all, as far as I know. debhelper uses a DH_COMPAT environment
> > variable or debian/compat file.
> 
> because there haven't been any such drastic changes in the normal policy
> as we had in the python policy - and, compat means something *very*
> different.

What does it mean? This thread more or less started when Raphael updated
dh_python to change behavior based on the presence/absence of the
Python-Standards-Version field -- exactly analogous to what debhelper's
compat levels are.

If it was just a tool for the RMs to track the migration, I'd not have a
problem with it[0], but the current proposal is that it actually affects
the package build. That's bad, and at odds with the way the rest of
debhelper (and all existing packaging tools) work.

[0] Except for the fact it's useless, because the presence/absence of a
XS-Python-Version tells the same thing. Which I said before.
-- 
Joe Wreschnig <piman@sacredchao.net>

Attachment: signature.asc
Description: This is a digitally signed message part


Reply to: