uploaded package handling
-----BEGIN PGP SIGNED MESSAGE-----
Having, I think settled on a .changes file format, we can now think
about what to do with them.
These are *my* thoughts on the matter, they certainly don't cover all
the possible ways of doing things but I think they do cover most of
the main functions required.
My idea is that the Distribution Maintainer (DM) need only look down
from on high at the process, issuing editcts covering section/priority
information and only coming down and getting involved when things go
wrong (and applying profuse apologies/thanks and/or the cattle-prod as
needed depending on whats at fault).
I like the idea of mailing in the .changes files rather than uploading
them so the system would have an email address to respond to with
errors/warnings/acknowledgments so this document assumes this,
however most of it applies to the situation where the .changes file is
uploaded with the rest of the files (as is the current situation).
UPLOADED PACKAGE HANDLING SYSTEM
Starting point: The UPHS gets a .changes file from somewhere.
First, the pgp signature (should be the current maintainer) on the
.changes is checked and only if it dosn't match or there isn't a
signature the DM needs to manual eye-ball the file to make sure its
ok. (This may change as things get going and we insist on a signed
file).
Next we need to check that the files refered to in the .changes file
exist, md5sums match. This may require looking for file like
<filename>-retry<n> and moving them to the correct filenames. The
information in the changes file should then be checked against the
contents of the .deb files provided and against current information to
make sure it is correct.
Next, check the .deb files. Several checks can be done:
a) Check that the new version > current version in the disribution
b) That is dons't have filename conflicts with packages that it
dosn't conflict with.
c) Section/Priority is allowed (see below).
d) file owner and group ids and permissions are sensible
e) lots more that I havn't thought of
Some of these checks can be done by the maintainer before hand if they
are supplied with the correct info and this should be encourgaged.
The outcome of these steps can be divided into 5 sets (the boundaries
will probably change over time).
Failure: something seriously wrong (bad signature, bad md5sums,
wrong info in changes file)
In this case an error message should be returned to the sender.
Errors: correctable mistakes - requires intervention of the DM
(conflicting information in .changes file/.deb files, conflicting
filenames that arn't really). These will probably all move
into Failures as the system matures.
In this case the DM has to decide if the package is ok enough
and possibly supply correct information. The decision is then
mailed to the sender.
Warnings: possible mistakes - nothing too serious.
( file permissions that don't look right, text files in
/usr/doc not compressed). As these problems are better
defined they may move to Errors or Failures.
The list of warnings is mailed to the sender - they may
decide to upload a new version correcting them (or wish
that the stupid program dies a horrible death).
Ok: everything is prefect (ah.. what a wonderful world).
An acknowledgement is sent to the sender.
The returned message should include all the actions taken so the
maintainer can check what is going on. They should also be
logged/sent to the DM.
If it is decided that the packages will be installed, they are moved
to the correct locations ("byhand" packages should be placed somewhere
for the DM along with a copy of the changes info). The various state
files (Packages, Contents) should perhaps be updated at this point,
the UPHS will already have had to parse them in to get the necesary
info.
A message should then be sent to the correct changes mailing list
telling everyone about the new wonderful package.
CHANGING MAINTAINER/DELETING PACKAGES
A .changes with a new maintainer field should be sent by the old
maintainer to "hand-over" the package. Currently a blank maintainer
orphans the package, I suggest that this be changed. Two "special"
maintainers names should be used "orphan" and "delete". Delete
.changes files should be carefully looked at.
STATE FILES
Currently there are two main "state" files Packages and Contents.
These would be used by the UPHS to determine what exactly needs to be
done and so need to be up-to-date. Currently the Contents file isn't
very useful, I propose that it should be changed to:
<filename> [<package> <version>]+
ie filename followed by a list of pairs of binary package names and
versions. This would allow a new .deb file to be checked for filename
conflicts.
Given a currentish copy of Packages and (new) Contents for a
particular distribution/architecture, a maintainer could check the
packages that are being uploaded using the same procedure as will be
used at the upload site - hopefully reducing errors.
Section/Distribution/Priority
Currently if a .deb file dosn't have to have a Section/Priority. The
reason is that the DM is responsible for setting these, however if we
are automating things it make sense for this to be set by the
maintainer before uploading. I propose that a maintainer may place a
package in any Section other than base and give a Priority of either
optional or extra without consulting the DM before hand (or just let
the DM see it when it gets uploaded and then a decision can be made).
The lack of Priority implies Optional (I think that is the lowest) and
lack of section implies the default section for the distribution.
[ I also note that Section/Priority information isn't making it's way
into the Packages file for every package correctly at the moment eg in
unstable: aout-svgalib, axs, cnews, deliver, ilu, imapd, inews, ipx,
libc5-pic, libg++27, libgr, libobjects, mdutils, mesa, modconf ....
(and then I got bored counting) ]
Note: that this proposal only refers to *newly* uploaded packages or packages
that don't already have a correct Section/Priority in the Packages
file at the moment.
I also propose a Distributions file which has the following fields for
each distribution.
Distribution: <space seperated list of distribution names>
Directory: <directory>
Sections: <space seperated list of sections allowed, default first>
UseSectDirs: <true if sections in there own directories>
Perhaps also:
Copyright: <some sort of copyright info>
(ie freeware, shareware, commerical...)
Description: <desc>
(ie This is unstable don't use).
Possibly other fields.
eg: currently:
Distribution: stable debian-0.93 debian-0.93R6
Directory: debian-0.93R6
UseSectDirs: Yes
Sections: misc admin base comm devel doc editors electronics games
graphics hamradio mail math net news shells sound tex X11
Distribution: unstable development
Directory: unstable
UseSectDirs: Yes
Sections: misc admin base comm devel doc editors electronics games
graphics hamradio mail math net news shells sound tex X11
Distribution: non-free
Directory: non-free
UseSectDirs: No
Sections: non-free
Distribution: contrib
Directory: contrib
UseSectDirs: No
Sections: contrib
Perhaps in the future non-free may start to overflow and it could be
changed to:
Distribution: non-free
Directory: non-free
UseSectDirs: Yes
Sections: non-free nf-mail nf-3dgraphics
Note that Section names are independent of distributions in this
proposal.
This could also be parsed by dpkg-ftp/dchanges to find a list of
possible Distributions.
Hope this is food for thought (and dosn't give anyone indigestion).
Andy.
-----BEGIN PGP SIGNATURE-----
Version: 2.6.2i
Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface
iQCVAwUBMWnNXl994FoFqUU1AQEjQwP/S99XKNdgGy8Qb6FhA+p2cjdYpWwXQO88
PtKN69fL9sGKwYVezbXQgS+nqatAhSgTbqVSbveZGzJZ6Mw8eKcTjrLhSVwiBvhe
7C2sxgS9BMt11tNebf15t1lQGbLzqIxF7SZ7t0dvAt+r74F3ZVcUURoqWhK3RK5d
zfFbeNXpJ9I=
=8tkd
-----END PGP SIGNATURE-----
Reply to: