Re: Policy Weekly Issue #4/4: Announcing new packages before uploading them
Hi,
I just tested changelog.el; it handles things just fine. Most
packages that parse changelog files should handle the additional
keyword just fine (or they are broken and should be fixed). Since the
keywords are already in the specs, backwards compatibility is not a
problem, as no changes to the spec are required. What programs do you
think are required to be modified?
dpkg-parsechangelog was not rejecting the closes keyword, it
was just informing us that it does not know what to do with it; and
by default it added a X-closes header (which is nice ;-).
We need to fix implement this once, not put a kludge in and
worry about backwards compatibility with the broken solution
forever.
Technically, there is one right solution; and that is to use
the keywords capability of the Debian changelog format.
As to how the bugs are closed, there is no reason that the
control interface be used; dinstall can use the
xxx-closed@bugs.debian.org just like release does now (send in the
changes file to close the report).
If there is a concern about how the bugs should be closed, we
decide on the right method on the list, rather than, as some people
have put it, run away, run away, and run to a kludge.
Parsing general changes with a static parser is a bad idea. It
is not as if we don't have an elegant solution. I also do not see why
it should take a while to implement this. Here: apply the patch, and
dpkg-parsechangelog shall implement the keyword. It won't do anything
with it apart from creating a field called Bugs_closed (I'm not sure
*what* I want to do with it unless it is dinstall I'm talking about)
======================================================================
++ /usr/lib/dpkg/parsechangelog/debian Wed Oct 29 21:00:41 1997
@@ -40,9 +40,10 @@
}
}
-%mapkv=(); # for future use
+%mapkv=("Closes" => "Bugs_closed"); # for future use
$i=100;grep($fieldimps{$_}=$i--,
- qw(Source Version Distribution Urgency Maintainer Date Changes));
+ qw(Source Version Distribution Urgency Maintainer Bugs_closed Date
+ Changes));
$i=1;grep($urgencies{$_}=$i++,
qw(low medium routine high urgent emergency));
======================================================================
Take a look at a dpkg-parsechangelog run below; I kinda like
the bugs closed field in the changes file. Nice code, BTW.
Ok? Oh, yes, it would be nice if the dpkg maintainers did say
something about the ease of implementation, since us munchkins can't
say anything authoritative.
manoj
--
"By long-standing tradition, I take this opportunity to savage other
designers in the thin disguise of good, clean fun." Plauger, from his
April Fool's column in April 88's "Computer Language"
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
==============================Changelog file==============================
make (3.76.1-3) unstable; urgency=low, closes=1200 1234 23489
* With Stellar help from Stephen Zander <srz@mckesson.com>, changed the
aclocal.m4 file (already present in the upstream sources) to override
the function that checks for libelf. This should now not create a
spurious dependency on libelfg0 even if the gremlins cause automake to
be run to recreate configure.
-- Manoj Srivastava <srivasta@debian.org> Wed, 29 Oct 1997 14:22:37 -0600
[snipped for brevity, regular changelog from here]
Local variables:
mode: debian-changelog
End:
======================================================================
==============================changes file===========================
__> dpkg-parsechangelog
Source: make
Version: 3.76.1-3
Distribution: unstable
Urgency: low
Maintainer: Manoj Srivastava <srivasta@debian.org>
Bugs_closed: 1200 1234 23489
Date: Wed, 29 Oct 1997 14:22:37 -0600
Changes:
make (3.76.1-3) unstable; urgency=low, closes=1200 1234 23489
.
* With Stellar help from Stephen Zander <srz@mckesson.com>, changed the
aclocal.m4 file (already present in the upstream sources) to override
the function that checks for libelf. This should now not create a
spurious dependency on libelfg0 even if the gremlins cause automake to
be run to recreate configure.
======================================================================
Reply to: