/usr/share/doc/xorg/reference/experimental.html is in xserver-xorg 1:7.6+12ubuntu1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
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 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<meta http-equiv="Content-Type" content="application/xhtml+xml; charset=UTF-8" />
<meta name="generator" content="AsciiDoc 8.6.6" />
<title>Handling multiple server versions thanks to experimental</title>
<link rel="stylesheet" href="../xsf.css" type="text/css" />
<script type="text/javascript" src="../asciidoc-xhtml11.js"></script>
<script type="text/javascript">
/*<![CDATA[*/
asciidoc.install();
/*]]>*/
</script>
</head>
<body class="article">
<div id="header">
<h1><a href="../index.html">XSF</a> / Handling multiple server versions thanks to experimental</h1>
<span id="author">Cyril Brulebois</span><br />
<span id="email"><tt><<a href="mailto:kibi@debian.org">kibi@debian.org</a>></tt></span><br />
</div>
<div id="content">
<div class="sect1">
<h2 id="_context">Context</h2>
<div class="sectionbody">
<div class="paragraph"><p>A quick overview of how things work upstream for the server:</p></div>
<div class="ulist"><ul>
<li>
<p>
Patches get reviewed and merged into the <tt>master</tt> branch.
</p>
</li>
<li>
<p>
After a few release candidates, <tt>master</tt> gets tagged (say: <tt>1.10</tt>
or <tt>1.10.0</tt>), and a stable branch (<tt>server-1.10-branch</tt> in this
case) is created to receive bug fixes.
</p>
</li>
<li>
<p>
Those bug fixes usually are cherry-picks from commits in the
<tt>master</tt> branch.
</p>
</li>
<li>
<p>
This leads to stable bugfix releases: <tt>1.10.1</tt>, <tt>1.10.2</tt>, and
so on.
</p>
</li>
</ul></div>
<div class="paragraph"><p>It doesn’t make much sense to try and package <tt>master</tt> on a continuous
fashion, since the ABI can be broken multiple times, without a bump
for the ABI version numbers every time. It’s usually done once a bunch
of major changes landed, and when things are supposed to be stable
for a while. On the packaging side, as explained on the
<a href="dependencies.html">dependencies between server and drivers</a> page,
a bump means the need for a rebuild of the relevant drivers (input
and/or video).</p></div>
<div class="paragraph"><p>That’s why the idea is to concentrate on upstream release candidates
and official releases. Depending on available developer time (both
upstream and in Debian), several branches can be developed/maintained
in parallel, so it can be worth having several versions available in
parallel, which is where <tt>experimental</tt> is handy.</p></div>
<div class="paragraph"><p>Keeping on with this example, with <tt>1.9</tt> in <tt>unstable</tt>, release
candidates for <tt>1.10</tt> can be uploaded to <tt>experimental</tt>, along with a
few drivers so that it’s actually useful.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_selecting_drivers">Selecting drivers</h2>
<div class="sectionbody">
<div class="paragraph"><p>To avoid repetitive and sometimes pointless work, it’s probably a good
idea to upload (to <tt>experimental</tt> as well) only a few drivers built
against the server in <tt>experimental</tt>. ABI might be bumped between
release candidates (that happened between <tt>1.10rc3</tt> and <tt>1.10</tt> for
example), so drivers would need to be rebuilt (even though binNMUs
might help).</p></div>
<div class="paragraph"><p>The proposed drivers can be seen on the
<a href="squeeze-backports.html">backports policy for squeeze</a> page, along
with a tiny description for each.</p></div>
</div>
</div>
<div class="sect1">
<h2 id="_building_drivers_in_experimental">Building drivers in experimental</h2>
<div class="sectionbody">
<div class="paragraph"><p>Having a driver in <tt>experimental</tt> doesn’t change much: It is sufficient
to declare a build-dependency against <tt>xserver-xorg-dev (>=
$serverminver)</tt>, where <tt>$serverminver</tt> can be seen in:</p></div>
<div class="ulist"><ul>
<li>
<p>
<tt>debian/serverminver</tt> in the <tt>xorg-server</tt> source package: see its
first line.
</p>
</li>
<li>
<p>
<tt>/usr/share/xserver-xorg/inputdrvdep</tt>: see the needed version of
<tt>xserver-xorg-core</tt>.
</p>
</li>
<li>
<p>
<tt>/usr/share/xserver-xorg/videodrvdep</tt>: ditto.
</p>
</li>
</ul></div>
<div class="paragraph"><p>So, for a given version of a driver in <tt>unstable</tt>, bumping the
build-dep version and uploading to <tt>experimental</tt> should be enough,
providing it doesn’t require further changes (source code changes are
sometimes needed to support building against a newer server). When
that happens, the revision number can be constructed by appending
<tt>+exp1</tt>. The idea here is to avoid things like:</p></div>
<div class="ulist"><ul>
<li>
<p>
<tt>1.42-1</tt> to <tt>unstable</tt>.
</p>
</li>
<li>
<p>
<tt>1.42-2</tt> to <tt>experimental</tt>: bump the build-dep.
</p>
</li>
<li>
<p>
<tt>1.42-3</tt> to <tt>unstable</tt>: revert the build-dep bump, add a bugfix.
</p>
</li>
<li>
<p>
<tt>1.42-4</tt> to <tt>experimental</tt>: build the build-dep again, keep the bugfix.
</p>
</li>
<li>
<p>
etc.
</p>
</li>
</ul></div>
<div class="paragraph"><p>Instead, that seems more natural:</p></div>
<div class="ulist"><ul>
<li>
<p>
<tt>1.42-1</tt> to <tt>unstable</tt>.
</p>
</li>
<li>
<p>
<tt>1.42-1+exp1</tt> to <tt>experimental</tt>: bump the build-dep.
</p>
</li>
<li>
<p>
<tt>1.42-2</tt> to <tt>unstable</tt>: add a bugfix to <tt>unstable</tt>’s version.
</p>
</li>
<li>
<p>
<tt>1.42-2+exp1</tt> to <tt>experimental</tt>: rebuild against experimental
(merging or rebasing the build-dep bump).
</p>
</li>
</ul></div>
<div class="sidebarblock">
<div class="content">
<div class="paragraph"><div class="title">Note</div><p>Remember <tt>experimental</tt> is special. With the above sequence of
uploads, if the <tt>1.42-2+exp1</tt> version isn’t uploaded, the
<tt>1.42-1+exp1</tt> upload might disappear from <tt>experimental</tt> after some
time, since the version in <tt>unstable</tt> is more recent: the “obsolete”
package goes away. That’s why it’s important to remember uploading to
<tt>experimental</tt> as well when uploading a new driver to <tt>unstable</tt>.</p></div>
</div></div>
</div>
</div>
</div>
<div id="footnotes"><hr /></div>
<div id="footer">
<div id="footer-text">
Last updated 2011-08-08 10:58:19 UTC
</div>
</div>
</body>
</html>
|