Re: changes file format
The following is taken from an email message I received from
sr1@irz.inf.tu-dresden.de. I hope he doesn't object to my
posting his email and my responses to debian-devel. I
think points made here could usefully contribute to the changes
file format discussion.
> In article <[🔎] Pine.SUN.3.91.951023172001.13049A-100000@bb29c> Bill Mitchell <mitchell@mdd.comm.mot.com> writes:
>
> > Just out of curiosity, does the following represent a horribly
> > formatted and human-unreadable package announcement? Except for
> > the lack of a Priority field, it passes the dchanges(1) syntax check.
>
> I omitted it because i didn't have a good idea what to write into it.
> (And I hoped that nobody will notice it ...)
Perhaps I should have made it clearer that I was holding your package
announcement up as an example of a readable announcement produced with
dchanges(1). Personally, I thought it was very clear and readable.
dchanges(1) requires a Priority field because there was one in the
package announcement format example from Bruce Perens, on which
dchanges(1) was based. I've been filling it in with whatever seemed
to fit (e.g., Emergency, High, Routine, Low, Important, Immediate).
My guess is that it's intended to be evaluated by a human.
> And the Changelog is hand-edited from a GNU Changelog-formatted file.
> An automatic conversion would be nice.
No doubt this could be easily done, if I knew exactly what the
GNU Changelog format looked like. If it's what I think it is,
I'd probably indent all lines with text by one single blank, and
convert totally blank lines to " ." lines. I wouldn't plan to do
this, however, until the recently-reopened discussion regarding what
package announcements should look like and what tools should be used
to produce them is done with, and the future (or lack thereof) of the
dchanges package is decided.
> another BTW: How do I specify that a package should go into the
> non-commercial section ? (The answer to this could belong into the
> manpage.)
What I've seen done, and done myself in that situation, is to
include a plaintext intro in the package announcemant to the effect
that "This package should go in non-free (or wherever) because ....".
I haven't had occasion to do this since I fielded the dchanges package.
If I did it using dchanges, I'd probably put "SECTION: non-free", or
whatever, in the package Control file. I'd probably include that
same information in plaintext in the debian-changes posting outside of
the portion of the text imported from the changes file produced
by dchanges(1) (or whatever tool replaces it).
Reply to: