Bruce and Bill: I'd like you to read the suggestions below in the
light of my recent comments on debian-private and see which of them
you agree with. Any that you both agree with go ahead and do, Bill,
the rest we can talk about :-).
1) Can there be an option to include a pre-prepared piece of text
given as a command line argument or on stdin or something as the
change info ? This option would imply -n (no edit) and you then need
an option which will turn the editing back on again.
2) Can the date please be in RFC822 format, rather than the default
`date' output ? Also, you're going to supply dates in local time at
the maintainer's address you should include the numeric timezone
information as well as or instead of the timezone abbreviation. See
the 822-date Perl script I posted recently for how to get this info.
3) Can it be arranged that a `source' field in one of or the first of
the .deb files is propagated into the output ?
4) When multiple .deb files are included, could you make the
Description field in the dchanges file be something like
info - Standalone GNU Info documentation browser
texinfo - The GNU Project's documentation formatting system
texidoc - Texinfo manual - how to write a Texinfo file
(ie, the package name and summary description from each package) ?
5) The manpage says:
.deb file specified. The dchanges program provides legal
but uninformative defaults for the Packages and Changes
fields. These defaults should be revised with more infor-
I hope this means "... defaults for the _Priority_ ...". If not, then
can the Package field be made to contain something sensible :-).
6) Can you please define what the effect is of multiple .deb files on
the Package field ? I suggest a comma-separated list.
7) Can we remove the `binary/base' &c file destination specification ?
This information should be provided by the distribution maintainer
(and they have to anyway, in the Packages file generator's override
file, which can be used for the purpose). In any case, if the
distribution maintainer wants to use information from the package
maintainer they can use the Section control file field.
8) Can we define a syntax for the Priority field ? I'd like it to be
a single word, one of LOW, MEDIUM, HIGH or URGENT, with an optional
comment in parentheses.
9) Can we define a `status' field, which is a series of words,
space-separated, some with predefined meanings, with an optional
comment in parentheses. The predefined meanings would be:
ALPHA, BETA - usual meaning
stable - this should be put into the stable tree, it is a
bugfix or very urgent release only
experimental - this is an experimental package which shouldn't go
into either release tree.
<something> - this should go into the bleeding-edge tree.
I don't know what <something> ought to be. "bleeding-edge" ? :-)
"new" ? I'm also not too enamoured with the name `status' for this
field. `stability' ?
10) I need a command-line option to specify the contents of the
priority field.
11) The -w option which warns about unreadable files should be the
default (and there should perhaps be a way to turn it off). By
default unreadable files should produce a non-zero exit status.
Ian.
