]> git.decadent.org.uk Git - dak.git/blob - docs/README.new-incoming
Merge commit 'lamby/master' into merge
[dak.git] / docs / README.new-incoming
1 [An updated version of the proposal sent to debian-devel-announce@l.d.o.  
2  Debian-specific, but useful as a general overview of New Incoming.]
3
4                      New Incoming System
5                      ===================
6
7 This document outlines the new system for handling Incoming
8 directories on ftp-master and non-US.
9
10 The old system:
11 ---------------
12
13   o incoming was a world writable directory
14
15   o incoming was available to everyone through http://incoming.debian.org/
16
17   o incoming was processed once a day by dinstall
18
19   o uploads in incoming had to have been there > 24 hours before they
20     were REJECTed.  If they were processed before that and had
21     problems they were SKIPped (with no notification to the maintainer
22     and/or uploader).
23
24 The new system:
25 ---------------
26
27   o There's 4 incoming directories:
28
29      @ "unchecked"  - where uploads from Queue Daemons and maintainers
30                       initially go.
31
32      @ "accepted"   - where accepted packages stay until the daily
33                       dinstall run.
34
35      @ "new"        - where NEW packages (and their dependents[1]) requiring
36                       human processing go after being automatically
37                       checked by dinstall.
38
39      @ "byhand"     - where BYHAND packages (and their dependents[1])
40                       requiring human intervention go after being
41                       automatically checked by dinstall.
42
43     In addition there's 3 support directories:
44
45      @ "reject"     - where rejected uploads go
46
47      @ "done"       - where the .changes files for packages that have been
48                       installed go.
49
50      @ "holding"    - a temporary working area for dinstall to hold
51                       packages while checking them.
52
53   o Packages in 'unchecked' are automatically checked every 15 minutes
54     and are either: REJECT, ACCEPT, NEW or BYHAND.
55
56   o Only 'unchecked' is locally world-writeable.  The others are all,
57     of course, locally world-readable but only 'accepted' and 'byhand'
58     are publicly visible on http://incoming.debian.org/
59
60   o 'accepted' and 'byhand' are made available to the auto-builders so
61      they can build out of them.
62
63   o 'accepted' is processed once a day as before.
64
65   o Maintainer/uploader & list notification and bug closures are
66     changed to be done for ACCEPTs, not INSTALLs. 
67     [Rationale: this reduces the load both on our list server and our
68      BTS server; it also gives people better notice of uploads to
69      avoid duplication of work especially, for example, in the case of
70      NMUs.]
71     [NB: see [3] for clarifications of when mails are sent.]
72
73 Why:
74 ----
75
76   o Security (no more replaceable file races)
77   o Integrity (new http://i.d.o contains only signed (+installable) uploads[2])
78   o Needed for crypto-in-main integration
79   o Allows safe auto-building out of accepted
80   o Allows previously-prohibitively-expensive checks to be added to dinstall
81   o Much faster feedback on packages; no more 48 hour waits before
82     finding out your package has been REJECTed.
83
84 What breaks:
85 ------------
86
87   o people who upload packages but then want to retract or replace the
88     upload.
89
90     * solution: mostly "Don't do that then"; i.e. test your uploads
91       properly.  Uploads can still be replaced, simply by uploading a
92       higher versioned replacement.  Total retraction is harder but
93       usually only relevant for NEW packages.
94
95 ================================================================================
96
97 [1] For versions of dependents meaning: binaries compiled from the
98     source of BYHAND or NEW uploads.  Due to dak's fascist
99     source-must-exist checking, these binaries must be held back until
100     the BYHAND/NEW uploads are processed.
101
102 [2] When this mail was initially written there was still at least one
103     upload queue which will accept unsigned uploads from any
104     source. [I've since discovered it's been deactivated, but not,
105     AFAIK because it allowed unsigned uploads.]
106
107 [3]
108              --> reject
109             /
110            /
111 unchecked  -----------------------------[*]------> accepted ---------------> pool
112            \               ^   ^
113             |             /   /
114             |-->   new  --   /
115             |       |[4]    /
116             |       V      /
117             |--> byhand --/
118
119 [4] This is a corner case, included for completeness, ignore
120     it. [Boring details: NEW trumps BYHAND, so it's possible for a
121     upload with both BYHAND and NEW components to go from 'unchecked'
122     -> 'new' -> 'byhand' -> 'accepted']
123