summaryrefslogtreecommitdiff
path: root/includes/etch/install/doc/FAQ/html/footnotes.html
diff options
context:
space:
mode:
Diffstat (limited to 'includes/etch/install/doc/FAQ/html/footnotes.html')
-rw-r--r--includes/etch/install/doc/FAQ/html/footnotes.html112
1 files changed, 112 insertions, 0 deletions
diff --git a/includes/etch/install/doc/FAQ/html/footnotes.html b/includes/etch/install/doc/FAQ/html/footnotes.html
new file mode 100644
index 000000000..37d57bb1e
--- /dev/null
+++ b/includes/etch/install/doc/FAQ/html/footnotes.html
@@ -0,0 +1,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
+&quot;sid&quot;. 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>
+