This discussion is a few days old, so let me summarize what it's about:
There was one aspect of the `new upload procedure' left where we didn't
had a consensus, namely, whether the changelog entry should be searched
for "closes:bug#xxx" tags at package build time or when the package is
actually installed to the archive (by dinstall).
On Tue, 3 Feb 1998, Ian Jackson wrote:
[snip]
> There are two reasons I can think of at the moment for putting the
> parsing into dpkg-parsechangelog.
>
> Firstly, dpkg-parsechangelog is currently the only program which needs
> to parse changlog text at all. dinstall just has to cut-and-paste
> it. I think that adding parsing of this data somewhere else is a
> doubtful idea.
>
> Secondly, the developer gets to choose their own changelog format
> (though few have actually done so). dpkg-parsechangelog is
> responsible for normalising this format. If we do the parsing there
> then we can change the user interface (what the developer has to do)
> without changing dinstall or requiring the change to be global.
>
> Both of these fundamentally stem from the fact that
> dpkg-parsechangelog is for parsing changelogs.
>
> Ian.
With these arguments, I agree that dpkg-parsechangelog should do the
parsing.
IIRC, this means that dpkg-parsechangelog will include a new `control
field' in the .changes file like this:
Closes: 1234 2345 3456
When dinstall installs a package, it searches for the "Closes:"
control field and closes the listed bugs. (Note, that dinstall will
not scan the changelog entry itself.)
With that, we need a volunteer now to implement this feature in
dpkg-parsechangelog. We already agreed on the following Perl regexp:
/closes:\s*(bug)?\#\d+(,\s*(bug)?\#\d+)*/i
Note, that the text may be wrapped over several lines. dpkg-parsechangelog
simply has to scan the changelog text for this pattern and include the
"Closes:" statement (like above) in the output file.
While we are at it:
It was also suggested that we change dpkg-gencontrol to copy the control
field Upload-Comment to the .changes file, too. dinstall can then search
for this control field and display its contents in the announcement mails.
(The .changes files are already reproduced verbosely, I think. So perhaps
we don't even have to implement this in dinstall.)
Another suggestion was to change the "Maintainer:" field to "Developer:",
"Uploader:" or whatever, since this field does not list the actual
maintainer taken from the control file, but the person listed in the
changelog entry (who might be someone else than the "Maintainer" of the
package, e.g., for NMU's). Opinions?
In summary, I think it would be good if we could get the new upload
procedure implemented soon, as it will make uploads and bug-closing easier
for the maintainers and more convenient for those who reported bugs. In
addition, it will avoid the `buggy' upload mails sent to debian-changes
instead of debian-devel-changes and, last but not least, we'll get rid of
all spam on the debian-*-changes lists!!
So it would be nice if we could hear some final comments on the changes
listed above and if a volunteer could step forward to implement the
changes in the dpkg-dev scripts.
Thanks,
Chris
-- Christian Schwarz
[EMAIL PROTECTED], [EMAIL PROTECTED]
[EMAIL PROTECTED], [EMAIL PROTECTED]
PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
CS Software goes online! Visit our new home page at
http://www.schwarz-online.com
