Re: PW#5-12: New upload procedure
On 15 Jan 1998, Guy Maor wrote:
> Christian Schwarz <schwarz@monet.m.isar.de> writes:
>
> > 3.) [check for new packages every ten minutes]
> > Check if package upload was complete and the files are correct
> > (i.e. check PGP signature, MD5 sums, correct .changes file, etc.)
> > If there is an error send mail to the maintainer and stop
> >
> > 4.) Send announcement to debian-devel-changes in case of an "unstable"
> > or "experimental" upload
> >
> > 5.) [once a day]
> > Install packages into the archive
> > (In case of a new package or a stable upload, this requires the
> > acknowledgement of the archive maintainer)
>
> Is all that really necessary? Currently dinstall runs once a day,
> rejects anything which fails pgp, md5, etc, and installs anything it
> can. I can announce the package as soon as dinstall sees it, even if
> it's new and might not get installed immediately.
The idea behind this is the following: Currently, the developer announces
the upload after having the file uploaded to Incoming. Since dinstall only
runs once a day there is a slight chance that a severe bug is detected and
fixed before dinstall processes the package. We'll use this possibility of
dinstall sends the announcement after installing the package into the
hierarchy.
Is this easy to implement for you?
> If someone is really burning to know if their upload is ok and they
> can't wait, they can run `dinstall -n foo.changes'.
No, the idea is to notify other maintainers about the upload before the
package gets installed, not as a verification of the upload for the
maintainer.
> > Fixes: 98765 98766 99999
>
> So dinstall will be scanning for this field, and not looking in the
> changelog? In other words, this will only work for people that have
> an updated dpkg-genchanges?
Well, we should probably discuss this point now. As I currently see, the
only disadvantage of having dinstall parseing the .changes file for
"fixes:" would be, that the maintainer can't check if these statements
will be parsed correctly.
Would you prefer scanning the .changes file? It would certainly be easier
to implement since this would not require any changes in dpkg-dev :)
> > 2. Before sending the announcement of the package upload, dinstall
> > will check the maintainer's home directory on master if it contains a
> > `~/.changes-template' file, in which case the file contents will be
>
> dinstall will only do this if the maintainer address is foo@debian.org, as
> the files' UID is wrong when it's coming from one of the upload queues.
Good point.
I was wondering why we need this feature, anyways. Wouldn't it be much
better if dpkg-genchanges would add such an additional text to the
.changes file? This way, the maintainer could easily change the text for
each upload (which will be some work if the insertion file is sitting on
master).
Thanks,
Chris
-- Christian Schwarz
schwarz@monet.m.isar.de, schwarz@schwarz-online.com,
Debian has a logo! schwarz@debian.org, schwarz@mathematik.tu-muenchen.de
Check out the logo PGP-fp: 8F 61 EB 6D CF 23 CA D7 34 05 14 5C C8 DC 22 BA
pages at http://fatman.mathematik.tu-muenchen.de/~schwarz/debian-logo/
Reply to: