| 1 |
wolf31o2 08/02/05 20:26:57 |
| 2 |
|
| 3 |
Modified: faq.xml |
| 4 |
Log: |
| 5 |
Updated the FAQ a little to mention that people should always build stages when doing their own builds. |
| 6 |
|
| 7 |
Revision Changes Path |
| 8 |
1.6 xml/htdocs/proj/en/releng/catalyst/faq.xml |
| 9 |
|
| 10 |
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/releng/catalyst/faq.xml?rev=1.6&view=markup |
| 11 |
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/releng/catalyst/faq.xml?rev=1.6&content-type=text/plain |
| 12 |
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/releng/catalyst/faq.xml?r1=1.5&r2=1.6 |
| 13 |
|
| 14 |
Index: faq.xml |
| 15 |
=================================================================== |
| 16 |
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/catalyst/faq.xml,v |
| 17 |
retrieving revision 1.5 |
| 18 |
retrieving revision 1.6 |
| 19 |
diff -u -r1.5 -r1.6 |
| 20 |
--- faq.xml 1 Dec 2005 23:55:58 -0000 1.5 |
| 21 |
+++ faq.xml 5 Feb 2008 20:26:57 -0000 1.6 |
| 22 |
@@ -13,142 +13,174 @@ |
| 23 |
Frequently asked questions relating to the Catalyst tool. |
| 24 |
</abstract> |
| 25 |
|
| 26 |
-<version>1.0</version> |
| 27 |
-<date>2005-12-01</date> |
| 28 |
+<version>1.1</version> |
| 29 |
+<date>2008-02-05</date> |
| 30 |
|
| 31 |
<chapter> |
| 32 |
<title>Frequently Asked Questions</title> |
| 33 |
|
| 34 |
<section> |
| 35 |
- <body> |
| 36 |
- <p> |
| 37 |
- <b>Q: How do I build a stage2 and stage3 tarball for a non-generic CPU |
| 38 |
- type, such as <c>pentium4</c> or <c>g4</c>?</b> |
| 39 |
- </p> |
| 40 |
- <p> |
| 41 |
- A: First, make sure that your hardware is capable of building such a |
| 42 |
- stage. If you want to build a <c>pentium4</c> stage, you will need to |
| 43 |
- build on a Pentium 4 or AMD64/Opteron system. You can't build a |
| 44 |
- <c>pentium4</c> stage on an Athlon XP system, as Athlon XP CPUs do not |
| 45 |
- support SSE2 instructions, and SSE2 instructions will be enabled for |
| 46 |
- <c>pentium4</c> stages. Likewise, if you want to build a <c>g4</c> |
| 47 |
- stage, you will need to do this on a PowerPC G4 or G5 system. |
| 48 |
- </p> |
| 49 |
- <p> |
| 50 |
- Once you've made sure that you're building on the right hardware, |
| 51 |
- simply follow the steps above, but for building the stage2, simply |
| 52 |
- change the <c>subarch</c> setting to a valid non-generic |
| 53 |
- subarchitecture (ie. <c>pentium4</c>.) Then your stage2 will be built |
| 54 |
- for the subarchitecture that you specify. Then, use this stage2 as the |
| 55 |
- "seed" stage to build your stage3. Of course, you will also want to |
| 56 |
- modify the <c>subarch</c> setting in your stage3 spec to match what you |
| 57 |
- used in your stage2 spec. |
| 58 |
- </p> |
| 59 |
- |
| 60 |
- <p> |
| 61 |
- <b>Q: I want to build a bunch of stages for various subarches. How |
| 62 |
- should I do this?</b> |
| 63 |
- </p> |
| 64 |
- <p>A: First, build a generic stage1. Then use this stage1 to build a |
| 65 |
- specialized stage2 and stage3. Use the stage1 again to build another |
| 66 |
- specialized stage2 and stage3. You do not need to re-build the stage1 |
| 67 |
- -- all your specialized stage2s and stage3s can use the same "seed" |
| 68 |
- stage1. |
| 69 |
- </p> |
| 70 |
- |
| 71 |
- <p> |
| 72 |
- <b>Q: Can I build a stage1 for a non-generic CPU type?</b> |
| 73 |
- </p> |
| 74 |
- <p>A: This is a very bad idea, as users expect stage1's to work on any |
| 75 |
- type of sub-architecture. This way, they can use the stage1 on any |
| 76 |
- system without worries. You should be sure to not "pollute" your |
| 77 |
- stage1 with non-generic-CPU-specific code. Always use a "generic" |
| 78 |
- stage2 or stage3 to build a new stage1. |
| 79 |
- </p> |
| 80 |
- |
| 81 |
- <p> |
| 82 |
- <b>Q: I thought that catalyst was able to build stages "from scratch." |
| 83 |
- If catalyst builds stages from scratch, then why does it need a "seed |
| 84 |
- stage"?</b> |
| 85 |
- </p> |
| 86 |
- <p>A: Good question. As you know, a stage2 and stage3 are dependent on |
| 87 |
- previous stages for building, which is expected and made clear by their |
| 88 |
- name (ie. a "stage2" implies that there was a "stage1".) However, |
| 89 |
- catalyst does need a seed stage for building a stage1, so in regards to |
| 90 |
- building a stage1 it's worth looking into why this is necessary. When |
| 91 |
- building a stage1, catalyst uses the seed (stage2 or stage3) to set up |
| 92 |
- a chroot environment. Inside the chroot environment, the new stage1 is |
| 93 |
- built by setting the <c>ROOT</c> environment variable to |
| 94 |
- <path>/tmp/stage1root</path>. This instructs Portage to merge all new |
| 95 |
- packages not to the current filesystem, but to the filesystem in |
| 96 |
- <path>/tmp/stage1root</path>. <path>/tmp/stage1root</path> is then |
| 97 |
- tarred up and becomes the target stage1. What this means is that when |
| 98 |
- catalyst builds a stage1, the stage1 itself does not inherit any |
| 99 |
- binaries or libraries from the seed that is used. The seed that is used |
| 100 |
- <e>does</e> impact the target stage1 somewhat -- the Linux headers on |
| 101 |
- the seed are used for building the stage1's glibc, and the compilers on |
| 102 |
- the seed are used to compile all the programs on the stage1. The seed |
| 103 |
- stage is used to isolate the stage1 build process from your local |
| 104 |
- system, and also allows for x86 stage1s to be built on amd64 systems, |
| 105 |
- for example. |
| 106 |
- </p> |
| 107 |
- |
| 108 |
- <p> |
| 109 |
- <b>Q: Is there an official HOWTO for Catalyst?</b> |
| 110 |
- </p> |
| 111 |
- <p> |
| 112 |
- Currently, there is no official HOWTO. If you are interested in |
| 113 |
- writing one though, please file a bug with the HOWTO attached to it. |
| 114 |
- The lack of an official HOWTO does not mean that Catalyst is completely |
| 115 |
- undocumented though. If Catalyst is emerged with the <c>doc</c> USE |
| 116 |
- flag set, well commented example specfiles are installed to |
| 117 |
- <path>/usr/share/doc/catalyst-$version/examples</path>. |
| 118 |
- </p> |
| 119 |
- <p> |
| 120 |
- If you still have questions after reading through the examples, feel |
| 121 |
- free to subscribe to the gentoo-catalyst mailing list. |
| 122 |
- </p> |
| 123 |
- |
| 124 |
- <p> |
| 125 |
- <b>Q: Where do I put per-package use flags, mask settings, etc.?</b> |
| 126 |
- </p> |
| 127 |
- <p> |
| 128 |
- Catalyst supports the configuration files in /etc/portage. Just add |
| 129 |
- the following to your spec file, and make sure that you use the same |
| 130 |
- <c>portage_confdir</c> setting for your seed stages as well: |
| 131 |
- </p> |
| 132 |
- <p> |
| 133 |
- portage_confdir: /path/to/custom/etc/portage |
| 134 |
- </p> |
| 135 |
- |
| 136 |
- <p> |
| 137 |
- <b>Q: Should I really build my own stage1 or just use one from a Gentoo |
| 138 |
- mirror?</b> |
| 139 |
- </p> |
| 140 |
- <p> |
| 141 |
- Stages from the latest Gentoo release should suffice, unless you are |
| 142 |
- planning to do a hardened build or wish to change profile settings |
| 143 |
- (i.e. USE flags, CFLAGS, etc). |
| 144 |
- </p> |
| 145 |
- |
| 146 |
- <p> |
| 147 |
- <b>Q: How do I keep my GRP/stages/LiveCD packages updated?</b> |
| 148 |
- </p> |
| 149 |
- <p> |
| 150 |
- Catalyst uses Portage for all of the building work, so all that you |
| 151 |
- have to do is regenerate your Portage snapshot and rebuild your |
| 152 |
- GRP/stages/LiveCD. Portage will follow all of its normal rules for |
| 153 |
- deciding which packages to update. |
| 154 |
- </p> |
| 155 |
- |
| 156 |
- <p> |
| 157 |
- <b>Q: Does Catalyst use any special USE flag syntax?</b> |
| 158 |
- </p> |
| 159 |
- <p> |
| 160 |
- No, Catalyst's USE flag syntax is exactly the same as Portage's. |
| 161 |
- </p> |
| 162 |
- </body> |
| 163 |
+<title>How do I build a stage2 and stage3 tarball for a non-generic CPU type, |
| 164 |
+such as pentium4?</title> |
| 165 |
+<body> |
| 166 |
+ |
| 167 |
+<p> |
| 168 |
+First, make sure that your hardware is capable of building such a stage. If |
| 169 |
+you want to build a <c>pentium4</c> stage, you will need to build on a Pentium |
| 170 |
+4 or AMD64/Opteron system (or better). You cannot build a <c>pentium4</c> stage |
| 171 |
+on an Athlon XP system, as Athlon XP CPUs do not support SSE2 instructions, and |
| 172 |
+SSE2 instructions will be enabled for <c>pentium4</c> stages. Likewise, if you |
| 173 |
+want to build a <c>g4</c> stage, you will need to do this on a PowerPC G4 or G5 |
| 174 |
+system. |
| 175 |
+</p> |
| 176 |
+<p> |
| 177 |
+Once you've made sure that you're building on the right hardware, simply follow |
| 178 |
+the steps above, but for building the stage2, simply change the <c>subarch</c> |
| 179 |
+setting to a valid non-generic subarchitecture (ie. <c>pentium4</c>.) Then your |
| 180 |
+stage2 will be built for the subarchitecture that you specify. Then, use this |
| 181 |
+stage2 as the "seed" stage to build your stage3. Of course, you will also want |
| 182 |
+to modify the <c>subarch</c> setting in your stage3 spec to match what you used |
| 183 |
+in your stage2 spec. |
| 184 |
+</p> |
| 185 |
+ |
| 186 |
+</body> |
| 187 |
+</section> |
| 188 |
+ |
| 189 |
+<section> |
| 190 |
+<title>I want to build a bunch of stages for various subarches. How should I |
| 191 |
+do this?</title> |
| 192 |
+<body> |
| 193 |
+ |
| 194 |
+<p> |
| 195 |
+First, build a generic stage1. Then use this stage1 to build a specialized |
| 196 |
+stage2 and stage3. Use the stage1 again to build another specialized stage2 and |
| 197 |
+stage3. You do not need to re-build the stage1 -- all your specialized stage2's |
| 198 |
+and stage3's can use the same "seed" stage1. |
| 199 |
+</p> |
| 200 |
+ |
| 201 |
+</body> |
| 202 |
+</section> |
| 203 |
+ |
| 204 |
+<section> |
| 205 |
+<title>Can I build a stage1 for a non-generic CPU type?</title> |
| 206 |
+<body> |
| 207 |
+ |
| 208 |
+<p> |
| 209 |
+This is a very bad idea, as users expect stage1's to work on any type of |
| 210 |
+subarchitecture. This way, they can use the stage1 on any system without |
| 211 |
+worries. You should be sure to not "pollute" your stage1 with non-generic |
| 212 |
+CPU-specific code. Always use a "generic" stage3 as a seed to build a new |
| 213 |
+stage1. |
| 214 |
+</p> |
| 215 |
+ |
| 216 |
+</body> |
| 217 |
</section> |
| 218 |
+ |
| 219 |
+<section> |
| 220 |
+<title>I thought that catalyst was able to build stages "from scratch." If |
| 221 |
+catalyst builds stages from scratch, then why does it need a "seed |
| 222 |
+stage"?</title> |
| 223 |
+<body> |
| 224 |
+ |
| 225 |
+<p> |
| 226 |
+Good question. As you know, a stage2 and stage3 are dependent on previous |
| 227 |
+stages for building, which is expected and made clear by their name (ie. a |
| 228 |
+"stage2" implies that there was a "stage1".) However, catalyst does need a |
| 229 |
+seed stage for building a stage1, so in regards to building a stage1 it's worth |
| 230 |
+looking into why this is necessary. When building a stage1, catalyst uses the |
| 231 |
+seed stage3 to set up a chroot environment. Inside the chroot environment, the |
| 232 |
+new stage1 is built by setting the <c>ROOT</c> environment variable to |
| 233 |
+<path>/tmp/stage1root</path>. This instructs the package manager to merge all |
| 234 |
+new packages not to the current filesystem, but to the filesystem in |
| 235 |
+<path>/tmp/stage1root</path>. Catalyst then tars up <path>/tmp/stage1root</path> |
| 236 |
+and it becomes the target stage1. What this means is that when catalyst builds |
| 237 |
+a stage1, the stage1 itself does not inherit any binaries or libraries from the |
| 238 |
+seed that is used. The seed that is used <e>does</e> impact the target stage1 |
| 239 |
+somewhat -- the Linux headers on the seed are used for building the stage1's |
| 240 |
+glibc, and the compilers on the seed are used to compile all the programs on |
| 241 |
+the stage1. The seed stage is used to isolate the stage1 build process from |
| 242 |
+your local system, and also allows for x86 stage1's to be built on amd64 |
| 243 |
+systems, for example. |
| 244 |
+</p> |
| 245 |
+ |
| 246 |
+</body> |
| 247 |
+</section> |
| 248 |
+ |
| 249 |
+<section> |
| 250 |
+<title>Is there an official HOWTO for Catalyst?</title> |
| 251 |
+<body> |
| 252 |
+ |
| 253 |
+<p> |
| 254 |
+Currently, there is no official HOWTO. If you are interested in writing one, |
| 255 |
+though, please file a bug with the HOWTO attached to it. The lack of an |
| 256 |
+official HOWTO does not mean that catalyst is completely undocumented, though. |
| 257 |
+When catalyst is emerged, a well commented set of example spec files are |
| 258 |
+installed to <path>/usr/share/doc/catalyst-$version/examples</path>. |
| 259 |
+</p> |
| 260 |
+<p> |
| 261 |
+If you still have questions after reading through the examples, feel |
| 262 |
+free to subscribe to the gentoo-catalyst mailing list. |
| 263 |
+</p> |
| 264 |
+ |
| 265 |
+</body> |
| 266 |
+</section> |
| 267 |
+ |
| 268 |
+<section> |
| 269 |
+<title>Where do I put per-package use flags, mask settings, etc.?</title> |
| 270 |
+<body> |
| 271 |
+ |
| 272 |
+<p> |
| 273 |
+Catalyst supports the configuration files in /etc/portage. Just add the |
| 274 |
+following to your spec file, and make sure that you use the same |
| 275 |
+<c>portage_confdir</c> setting for your seed stages as well: |
| 276 |
+</p> |
| 277 |
+<p> |
| 278 |
+portage_confdir: /path/to/custom/etc/portage |
| 279 |
+</p> |
| 280 |
+ |
| 281 |
+</body> |
| 282 |
+</section> |
| 283 |
+ |
| 284 |
+<section> |
| 285 |
+<title>Should I really build my own stage1 or just use one from a Gentoo |
| 286 |
+mirror?</title> |
| 287 |
+<body> |
| 288 |
+ |
| 289 |
+<p> |
| 290 |
+It is best practice to <b>always</b> build your own stages if you are not using |
| 291 |
+the same snapshot that was used to build the last release. The state of the tree |
| 292 |
+is very much dependent on itself. If you have a stage1 from 3 months ago, it is |
| 293 |
+very likely that you will run into problems with blockers and other changes in |
| 294 |
+the tree that will cause you build or compatibility problems. |
| 295 |
+</p> |
| 296 |
+ |
| 297 |
+</body> |
| 298 |
+</section> |
| 299 |
+ |
| 300 |
+<section> |
| 301 |
+<title>How do I keep my GRP/stages/LiveCD packages updated?</title> |
| 302 |
+<body> |
| 303 |
+ |
| 304 |
+<p> |
| 305 |
+Catalyst uses Portage for all of the building work, so all that you have to do |
| 306 |
+is regenerate your Portage snapshot and rebuild your GRP/stages/LiveCD. Portage |
| 307 |
+will follow all of its normal rules for deciding which packages to update. |
| 308 |
+</p> |
| 309 |
+ |
| 310 |
+</body> |
| 311 |
+</section> |
| 312 |
+ |
| 313 |
+<section> |
| 314 |
+<title>Does Catalyst use any special USE flag syntax?</title> |
| 315 |
+<body> |
| 316 |
+ |
| 317 |
+<p> |
| 318 |
+No, catalyst's USE flag syntax is exactly the same as portage's. |
| 319 |
+</p> |
| 320 |
+ |
| 321 |
+</body> |
| 322 |
+</section> |
| 323 |
+ |
| 324 |
</chapter> |
| 325 |
|
| 326 |
</guide> |
| 327 |
|
| 328 |
|
| 329 |
|
| 330 |
-- |
| 331 |
gentoo-commits@l.g.o mailing list |
Archives