Automating the upload process

[bruce@Pixar.com (Bruce Perens)]

Bill, Bdale, & co.,

A while ago I had asked for the format of .changes files to include the
file _destination_ along with the file name, length, and MD5 checksum.
This issue becomes even more important with the introduction of
multiple architectures. I think we should add the destination to the
changes file now. Bill has done this before, and can no doubt put the
feature back in easily. I trust the maintainers to get this information
right, and we'll have an audit trail if they get it wrong. The
automated upload process will post information derived from the
changes file to debian-changes mailing list _in_a_different_format_,
so the esthetics of the presentation of this field should take a
back-seat here.

I propose we use the following field for each file:

File: name destination-directory length md5-checksum

For example:

# File: name destination-directory length md5-checksum
File: base-1.1-1.68k.deb development/68k/base 10245678
 0x102020202020202020202202020
File: base-1.1-1.i386.deb development/i386/base 10245678
 0x102020202020202020202202020
File: base-1.1-1.tar.gz development/source/base 10245678
 0x102020202020202020202202020

Destination-directory must be a relative pathname, and must not contain
".." in any path element. Other tests will be applied to the destination field
to avoid simple maintainer mistakes. I don't know what the current thought on
architecture letters for packages is, my use of .i386. and .68k. is not
meant to be a proposal on that topic.

I also would like to see the "Maintainer: " field exported to the .changes
file so that the upload script could complain to the maintainer. We might
want the "Maintainer: " field to be a proper RFC-822 mail address, for
example "(Bruce Perens) Bruce@Pixar.com" rather than the deprecated form
of mail address we are currently using.

	Thanks

	Bruce
--
Bruce Perens <Bruce@Pixar.com>
Pixar Animation Studios - Reality is not our business.