* 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]