Re: Automating the upload process
bruce@pixar.com Mon Feb 19 15:04:25 1996
> 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
Not so long ago we had a real furball of a discussion regarding
changes file cosmetics. As a result of that discussion, dchanges
was modified from producing changes files Files information in a
format something like this into producing its current format.
Personally, I don't have a strong preference either way. IMHO,
package announcements should be automated and made from the
upload site after the uploaded material has been placed into
the distribution, and the automated announcer should address
cosmetics. dchanges should provide input to the automated
package processing scripts..
There was a strong preference from one camp, however, for two things:
1. familiar-looking stuff (hence the current `ls -l' output).
2. dchanges lines which can be fed to "md5sum -c" (which works
with the current changes file if the initial char of each line
is chopped off)
The first point is cosmetic, the second practical. Would it perhaps
be better to replace the `ls -l` lines with something like
123456 development/68k/base/base-1.1-1.68k.deb
... that is, the size, followed by the full relative destination pathname?
Please let me know what you want done about defaulting this information.
"development" is a reasonable default, and "base/base-1.1-1.deb" can come
from the .deb filename and the SOURCE: field of the control file (or be
"misc" if not specified). "68k", however, is a problem. If dchanges(1)
is to put it in, dchanges(1) should get the information from the package
control file. I'd suggest adding an ARCHITECTURE: field to the control
file, and defaulting it to "i386" if not present.
This, I guess, would supersede my just-posted reaction to bdale's
suggestion for a distribution tag in the changes file. This would be
one line per file, followed by md5sum lines in the current format.
Also, both `ls -l` and md5sum lines are presently placed in a "Files:"
field of the changes file. It probably makes sense to put the size+path
info in the "Files:" field, and put the md5sum in a new "Md5sum:" field.
Also, if we're going to be opening the control file definition up
again, how about adding a DOSNAME: field to it so that MSDOS
filename linking can be automated? I guess this means another
changes file field, something like:
Dosnames:
setserial setsrial
[...]
dchanges(1) might default this by truncation of the unix-style package
name, but I don't think dchanges(1) should try to detect namspace
collisions. I think namespace collision detection should be done on
the upload site, and not by dchanges(1).
> 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.
What's easy to provide is the contents of the "Maintainer:" field
from the control file from the first .deb package encountered.
Reply to: