Re: Automating the upload process
> 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 familliar-looking stuff belongs in the announcement posted to
debian-changes. I will make the script that does that posting output
the exact same format that is now used in "dchanges". For the
transition period (before automation goes in place) we may not have
that nicety, but I think we can tolerate that. Note that some of the reason
we were using the previous format was because the upload procedure was
_not_ automated, and Ian Murdock wanted to be able to compare listings
by hand. We no longer have a volunteer willing to hand-check uploads.
Ian's class load is too high for him to do this any longer. Thus, we
need to automate the upload procedure.
> Please let me know what you want done about defaulting this information.
More on that issue below.
The order within the field isn't particularly important to me, as long
as the requested fields are there and all information about a file is in
one field. Please make a prototype. I will test it out with a suitable
upload script and get approval from Bdale on the entire scheme. He's the
final authority for FTP, I'm just helping him with this issue.
> "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).
The default should be "development/i386/XXX/filename" for binary packages
unless you can figure out the subsection from the SOURCE: field, in which
case you should use it. I like XXX, as it cries out for the maintainer to
edit in the correct value. Since XXX will be a non-existant directory, the
upload script will be able to detect if the maintainer fails to make this
> I'd suggest adding an ARCHITECTURE: field to the control
> file, and defaulting it to "i386" if not present.
I don't mind that if Ian Jackson doesn't. I suggest that the .deb file
name have an architecture letter or something, as having identically-named
files with different contents is going to lead to confusion. I have not
been following the architecture-letter discussion but I think _some_ sort
of disambiguation within the file name is necessary.
> It probably makes sense to put the size+path
> info in the "Files:" field, and put the md5sum in a new "Md5sum:" field.
I really would like to see all of the information for one file placed in
one field, rather than a separate "Files" and "Md5sum" field. I will
preserve the current format in the annoucement that is posted to
> how about adding a DOSNAME: field to it so that MSDOS
> filename linking can be automated?
It already is automated.
> 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 would prefer to use the dos-names function from "mkisofs", if I have to
work on this script at all. This doesn't require that the package maintainer
set the name.
> What's easy to provide is the contents of the "Maintainer:" field
> from the control file from the first .deb package encountered.
That's fine. In general the address in that field already works for mail,
though the program has to understand old-format email addresses with angle
brackets around them.
Bruce Perens <Bruce@Pixar.com>
Pixar Animation Studios - Reality is not our business.