* Joe Wreschnig ([EMAIL PROTECTED]) [060620 07:14]:
> On Tue, 2006-06-20 at 06:49 +0200, Andreas Barth wrote:
> > * Raphael Hertzog ([EMAIL PROTECTED]) [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. Perhaps there is reason to use even both fields, I'm not
arguing against pycompat (and lots of your reasons are correct).

> X-Python-Standards-Version tried to overload one with the other. That's
> a recipe for disaster. Besides, eventually Python policy will be merged
> into real policy (hah hah, right) and then the field will exist only to
> give tool implementation details.

I doubt it will be ever merged in. I expect it will be rather become a
real subpolicy.


Cheers,
Andi
-- 
  http://home.arcor.de/andreas-barth/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to