1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-1">
<title>The Debian GNU/Linux FAQ - Footnotes</title>
</head>
<body>
<hr>
<h1>
The Debian GNU/Linux FAQ
<br>Footnotes</h1>
<h2><a href="ch-ftparchives.en.html#fr1" name="f1">1</a></h2>
<p>
When the present-day sid did not exist, the FTP site organization had one major
flaw: there was an assumption that when an architecture is created in the
current unstable, it will be released when that distribution becomes the new
stable. For many architectures that isn't the case, with the result that those
directories had to be moved at release time. This was impractical because the
move would chew up lots of bandwidth.
</p>
<p>
The archive administrators worked around this problem for several years by
placing binaries for unreleased architectures in a special directory called
"sid". For those architectures not yet released, the first time they
were released there was a link from the current stable to sid, and from then on
they were created inside the unstable tree as normal. This layout was somewhat
confusing to users.
</p>
<p>
With the advent of package pools (see <a href="#s-pools">What's in the
<samp>pool</samp> directory?, Section 5.10</a>), binary packages began to be
stored in a canonical location in the pool, regardless of the distribution, so
releasing a distribution no longer causes large bandwidth consumption on the
mirrors (there is, however, a lot of gradual bandwidth consumption throughout
the development process).
</p>
<h2><a href="ch-ftparchives.en.html#fr2" name="f2">2</a></h2>
<p>
<samp>dists/stable/main</samp>, <samp>dists/stable/contrib</samp>,
<samp>dists/stable/non-free</samp>, and <samp>dists/unstable/main/</samp>, etc.
</p>
<h2><a href="ch-ftparchives.en.html#fr3" name="f3">3</a></h2>
<p>
Historically, packages were kept in the subdirectory of <samp>dists</samp>
corresponding to which distribution contained them. This turned out to cause
various problems, such as large bandwidth consumption on mirrors when major
changes were made. This was fixed with the introduction of the package pool.
</p>
<p>
The <samp>dists</samp> directories are still used for the index files used by
programs like <samp>apt</samp>. You may also still see paths containing
<samp>dists/potato</samp> or <samp>dists/woody</samp> in the Filename header
field of some older packages.
</p>
<h2><a href="ch-pkgtools.en.html#fr4" name="f4">4</a></h2>
<p>
Notice that there are ports that make this tool available with other package
management systems, like Red Hat package manager, also known as
<code>rpm</code>
</p>
<h2><a href="ch-pkgtools.en.html#fr5" name="f5">5</a></h2>
<p>
Although this can also lead to systems with more packages installed than they
actually need to work.
</p>
<h2><a href="ch-support.en.html#fr6" name="f6">6</a></h2>
<p>
Use the debian-<var>list-subject</var>-REQUEST@lists.debian.org address for
that.
</p>
<hr>
<p>
The Debian GNU/Linux FAQ
</p>
<address>
version 3.1.5, 17 January 2007<br>
<br>
Authors are listed at <a href="ch-faqinfo.en.html#s-authors">Debian FAQ Authors</a><br>
<br>
</address>
<hr>
</body>
</html>
|
