Hi,
On Tue, 01 Jun 2010, Russ Allbery wrote:
> If this is still a supported feature, could you take over this
> documentation and add it to dpkg-parsechangelog or a new deb-changelog
> man page? If it is not a supported feature, please let me know and I'll
> just delete the information from Policy.
It's a supported feature but I have never heard of anyone using it.
I'm ok with integrating the relevant information in dpkg-parsechangelog(1).
BTW, the information is even outdated as the set of options that a
changelog parser must support has been extended in lenny.
I'm copying the relevant section here so that you can remove it from policy and
we can still look it up easily:
----
C.2.2.1 Defining alternative changelog formats
It is possible to use a different format to the standard one, by providing a
parser for the format you wish to use.
In order to have dpkg-parsechangelog run your parser, you must include a line
within the last 40 lines of your file matching the Perl regular expression:
\schangelog-format:\s+([0-9a-z]+)\W The part in parentheses should be the name
of the format. For example, you might say:
@@@ changelog-format: joebloggs @@@
Changelog format names are non-empty strings of alphanumerics.
If such a line exists then dpkg-parsechangelog will look for the parser as
/usr/lib/dpkg/parsechangelog/format-name or
/usr/local/lib/dpkg/parsechangelog/format-name; it is an error for it not to
find it, or for it not to be an executable program. The default changelog
format is dpkg, and a parser for it is provided with the dpkg package.
The parser will be invoked with the changelog open on standard input at the
start of the file. It should read the file (it may seek if it wishes) to
determine the information required and return the parsed information to
standard output in the form of a series of control fields in the standard
format. By default it should return information about only the most recent
version in the changelog; it should accept a -vversion option to return changes
information from all versions present strictly after version, and it should
then be an error for version not to be present in the changelog.
The fields are:
* Source
* Version (mandatory)
* Distribution (mandatory)
* Urgency (mandatory)
* Maintainer (mandatory)
* Date
* Changes (mandatory)
If several versions are being returned (due to the use of -v), the urgency
value should be of the highest urgency code listed at the start of any of the
versions requested followed by the concatenated (space-separated) comments from
all the versions requested; the maintainer, version, distribution and date
should always be from the most recent version.
For the format of the Changes field see Changes, Section 5.6.18.
If the changelog format which is being parsed always or almost always leaves a
blank line between individual change notes these blank lines should be stripped
out, so as to make the resulting output compact.
If the changelog format does not contain date or package name information this
information should be omitted from the output. The parser should not attempt to
synthesize it or find it from other sources.
If the changelog does not have the expected format the parser should exit with
a nonzero exit status, rather than trying to muddle through and possibly
generating incorrect output.
A changelog parser may not interact with the user at all.
----
Cheers,
--
Raphaël Hertzog
Like what I do? Sponsor me: http://ouaza.com/wp/2010/01/05/5-years-of-freexian/
My Debian goals: http://ouaza.com/wp/2010/01/09/debian-related-goals-for-2010/
--
To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
