I'm taking these as statements of incremental changes desired to the
current dchanges-produced format.
Ian Jackson <[EMAIL PROTECTED]> said:
> 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.
I must misunderstand. It sounds to me as if either the -c or -f option
does this, depending on how much of the otherwise-dchanges-generated
information is included in the pre-prepared piece of text. This
sounds like what I use the -c option for -- it causes dchanges to
omit generating the Priority and Changes fields, and takes what
it finds in the specified file and slaps that into the changes
at the point where the Priority and Changes fields would have been
put.
> 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.
I could probably dig up a copy of the script and figure out the perl,
even though I'm not a perl programmer. However, it sounds like you
want the output of `date -u "+%d %m %y %H:%M:%S UT"`, right?
> 3) Can it be arranged that a `source' field in one of or the first of
> the .deb files is propagated into the output ?
What's a "source" field? I checked a couple of .deb files, and don't
find one. What to do if it's not found?
> 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) ?
Could do -- to use the terminology used in the dchanges(1) man page,
the Description field would be blank, and would be followed by an
extended description with one line per .deb file, giving the package
name and the contents of the initial line of the package's Description
field.
> 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 :-).
Oops.
> 6) Can you please define what the effect is of multiple .deb files on
> the Package field ? I suggest a comma-separated list.
Currently, either the package field from the first .deb file encountered
is used, or whatever's specified with the -p "package field contents"
option. A blank-delimited list of packages is put in the Description
field in this case.
How about a blank-delimited list in the Package field, if multiple packages
are specified, with the Description field treated as discussed below?
> 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.
Do I hear any objections to this?
> 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.
Syntax-checked?
Case-insensitive? (if not case-insensitive, how about using lowercase?)
I'd like to omit (forbid, if syntax-checked) the optional comment in parens.
An extended field can be used for that, with the current syntax.
Priority: Urgent
If this isn't installed right away, bad things will happen
Please be sure to do it immediately.
> 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' ?
I can put in new fields, and syntax-check them to be sure that they
contain what's expected. The syntax requirements are currently very
simple, and I think we should strive not to overcomplicate them. For
the Status field, please define precisely what's expected. I'd
suggest, possibly, something like:
Release - In general Release
Trial - Released for field trial
Beta - Beta release (to friendly general users)
Alpha - Alpha release (to insiders)
Devel - In development
Applying this to the way things currently work, most packages would
go directly to Release. These would be debianized upstream packages.
Some packages would stay in Devel for a while, then Alpha, Beta, Release
(e.g., dpkg).
Also, as explained on the man page, the current syntax rules have all
fields required to appear once and only once, except for the File
field which must appear at least once. I'm presuming that this
applies to any additional fields you define, unless you state
otherwise.
> 10) I need a command-line option to specify the contents of the
> priority field.
OK.
>
> 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.
I disagree. I don't have really strong feelings about this, but
my disagreement is not just pulled out of the air on a whim.
I originally proposed a pretty baroque method of figuring out what
files to include, to avoid requiring the user to type a long list.
Bruce suggested wildcards (e.g., "dchanges kermit*". That might
get some File fields produced for unwanted files, and those are
easy to edit out. However, if "kermit*" includes directories or
symlinks to directories, dchanges can't produce reasonable File
fields for those so it skips them. My initial implementation had
dchanges complaining about this, and I turned it off because that
particular complaint was always a "so what? I don't care." item.
I think it's counterproductive to moan about things which are ususally
non-problems, not requiring action to solve them. If more moaning
is desired, the program can be put in crybaby mode -- and that's
what "-w" does. Perhaps I should change "warn" to "moan" or "complain".
So, I take your desired output format to be something like:
Date: 26 10 95 14:23:58 UT
Package: abc-1.2.3-4.deb def-4.5.6-7.deb ghi-1.3.5-7.deb
Version: 1.2.3-4
Description:
abc - children's alphabet tutor
def - "defend", the game
ghigragleflaggor - the program of the same name
.
This is Changelog info from a pre-prepared file.
It was included literally, except for having blank lines coerced.
.
* This might be a description of some change
.
* This might be a very long anc verbose description of some
change which the package maintainer goes on and on about.
.
* This might be the description of another change.
.
This might be some yammering from the maintainer. Yammer yammer
yammer yammer yammer yammer yammer yammer yammer yammer yammer
yammer yammer yammer yammer yammer yammer yammer yammer yammer
yammer yammer yammer.
Priority: Urgent
If this isn't installed right away, bad things will happen
Please be sure to do it immediately.
# File: <md5sum> <size> <name>
1526393bacda57822bfsc52728b1b243 101456789 abc-1.2.3-4.deb
12345678901234567890123456789012 123456 def-4.5.6-7.deb
11111111112222222222333333333344 2468 ghi-1.3.5-7.deb
90834912734971290479047910490849 907907979 sillystuff-12.34-56.tar.gz
91827309749071490790749017497947 12 sillystuff-12.34-56.diff.gz
How about the practice of taking the version info from the initial
.deb file encountered? Should there be a command-line override?
If multiple .deb files are specified, should there be a check that
all have the same version?
What about order of fields? Should dchanges generate them in any
particular order? Should the syntax-check care about order?
I had a pretty good idea what was desired the first time around, but
I don't have confidence that I'm reading your mind very well on
some points. I'd like to avoid implementing in a "I'll know what I
like when I see it" situation.
Should we be carrying this discussion out in debian-devel?
I doubt that most subscribers are interested?
