wolf31o2 08/02/05 20:26:57
Modified: faq.xml
Log:
Updated the FAQ a little to mention that people should always build stages when doing their own builds.
Revision Changes Path
1.6 xml/htdocs/proj/en/releng/catalyst/faq.xml
file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/releng/catalyst/faq.xml?rev=1.6&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/releng/catalyst/faq.xml?rev=1.6&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/releng/catalyst/faq.xml?r1=1.5&r2=1.6
Index: faq.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/releng/catalyst/faq.xml,v
retrieving revision 1.5
retrieving revision 1.6
diff -u -r1.5 -r1.6
--- faq.xml 1 Dec 2005 23:55:58 -0000 1.5
+++ faq.xml 5 Feb 2008 20:26:57 -0000 1.6
@@ -13,142 +13,174 @@
Frequently asked questions relating to the Catalyst tool.
</abstract>
-<version>1.0</version>
-<date>2005-12-01</date>
+<version>1.1</version>
+<date>2008-02-05</date>
<chapter>
<title>Frequently Asked Questions</title>
<section>
- <body>
- <p>
- <b>Q: How do I build a stage2 and stage3 tarball for a non-generic CPU
- type, such as <c>pentium4</c> or <c>g4</c>?</b>
- </p>
- <p>
- A: First, make sure that your hardware is capable of building such a
- stage. If you want to build a <c>pentium4</c> stage, you will need to
- build on a Pentium 4 or AMD64/Opteron system. You can't build a
- <c>pentium4</c> stage on an Athlon XP system, as Athlon XP CPUs do not
- support SSE2 instructions, and SSE2 instructions will be enabled for
- <c>pentium4</c> stages. Likewise, if you want to build a <c>g4</c>
- stage, you will need to do this on a PowerPC G4 or G5 system.
- </p>
- <p>
- Once you've made sure that you're building on the right hardware,
- simply follow the steps above, but for building the stage2, simply
- change the <c>subarch</c> setting to a valid non-generic
- subarchitecture (ie. <c>pentium4</c>.) Then your stage2 will be built
- for the subarchitecture that you specify. Then, use this stage2 as the
- "seed" stage to build your stage3. Of course, you will also want to
- modify the <c>subarch</c> setting in your stage3 spec to match what you
- used in your stage2 spec.
- </p>
-
- <p>
- <b>Q: I want to build a bunch of stages for various subarches. How
- should I do this?</b>
- </p>
- <p>A: First, build a generic stage1. Then use this stage1 to build a
- specialized stage2 and stage3. Use the stage1 again to build another
- specialized stage2 and stage3. You do not need to re-build the stage1
- -- all your specialized stage2s and stage3s can use the same "seed"
- stage1.
- </p>
-
- <p>
- <b>Q: Can I build a stage1 for a non-generic CPU type?</b>
- </p>
- <p>A: This is a very bad idea, as users expect stage1's to work on any
- type of sub-architecture. This way, they can use the stage1 on any
- system without worries. You should be sure to not "pollute" your
- stage1 with non-generic-CPU-specific code. Always use a "generic"
- stage2 or stage3 to build a new stage1.
- </p>
-
- <p>
- <b>Q: I thought that catalyst was able to build stages "from scratch."
- If catalyst builds stages from scratch, then why does it need a "seed
- stage"?</b>
- </p>
- <p>A: Good question. As you know, a stage2 and stage3 are dependent on
- previous stages for building, which is expected and made clear by their
- name (ie. a "stage2" implies that there was a "stage1".) However,
- catalyst does need a seed stage for building a stage1, so in regards to
- building a stage1 it's worth looking into why this is necessary. When
- building a stage1, catalyst uses the seed (stage2 or stage3) to set up
- a chroot environment. Inside the chroot environment, the new stage1 is
- built by setting the <c>ROOT</c> environment variable to
- <path>/tmp/stage1root</path>. This instructs Portage to merge all new
- packages not to the current filesystem, but to the filesystem in
- <path>/tmp/stage1root</path>. <path>/tmp/stage1root</path> is then
- tarred up and becomes the target stage1. What this means is that when
- catalyst builds a stage1, the stage1 itself does not inherit any
- binaries or libraries from the seed that is used. The seed that is used
- <e>does</e> impact the target stage1 somewhat -- the Linux headers on
- the seed are used for building the stage1's glibc, and the compilers on
- the seed are used to compile all the programs on the stage1. The seed
- stage is used to isolate the stage1 build process from your local
- system, and also allows for x86 stage1s to be built on amd64 systems,
- for example.
- </p>
-
- <p>
- <b>Q: Is there an official HOWTO for Catalyst?</b>
- </p>
- <p>
- Currently, there is no official HOWTO. If you are interested in
- writing one though, please file a bug with the HOWTO attached to it.
- The lack of an official HOWTO does not mean that Catalyst is completely
- undocumented though. If Catalyst is emerged with the <c>doc</c> USE
- flag set, well commented example specfiles are installed to
- <path>/usr/share/doc/catalyst-$version/examples</path>.
- </p>
- <p>
- If you still have questions after reading through the examples, feel
- free to subscribe to the gentoo-catalyst mailing list.
- </p>
-
- <p>
- <b>Q: Where do I put per-package use flags, mask settings, etc.?</b>
- </p>
- <p>
- Catalyst supports the configuration files in /etc/portage. Just add
- the following to your spec file, and make sure that you use the same
- <c>portage_confdir</c> setting for your seed stages as well:
- </p>
- <p>
- portage_confdir: /path/to/custom/etc/portage
- </p>
-
- <p>
- <b>Q: Should I really build my own stage1 or just use one from a Gentoo
- mirror?</b>
- </p>
- <p>
- Stages from the latest Gentoo release should suffice, unless you are
- planning to do a hardened build or wish to change profile settings
- (i.e. USE flags, CFLAGS, etc).
- </p>
-
- <p>
- <b>Q: How do I keep my GRP/stages/LiveCD packages updated?</b>
- </p>
- <p>
- Catalyst uses Portage for all of the building work, so all that you
- have to do is regenerate your Portage snapshot and rebuild your
- GRP/stages/LiveCD. Portage will follow all of its normal rules for
- deciding which packages to update.
- </p>
-
- <p>
- <b>Q: Does Catalyst use any special USE flag syntax?</b>
- </p>
- <p>
- No, Catalyst's USE flag syntax is exactly the same as Portage's.
- </p>
- </body>
+<title>How do I build a stage2 and stage3 tarball for a non-generic CPU type,
+such as pentium4?</title>
+<body>
+
+<p>
+First, make sure that your hardware is capable of building such a stage. If
+you want to build a <c>pentium4</c> stage, you will need to build on a Pentium
+4 or AMD64/Opteron system (or better). You cannot build a <c>pentium4</c> stage
+on an Athlon XP system, as Athlon XP CPUs do not support SSE2 instructions, and
+SSE2 instructions will be enabled for <c>pentium4</c> stages. Likewise, if you
+want to build a <c>g4</c> stage, you will need to do this on a PowerPC G4 or G5
+system.
+</p>
+<p>
+Once you've made sure that you're building on the right hardware, simply follow
+the steps above, but for building the stage2, simply change the <c>subarch</c>
+setting to a valid non-generic subarchitecture (ie. <c>pentium4</c>.) Then your
+stage2 will be built for the subarchitecture that you specify. Then, use this
+stage2 as the "seed" stage to build your stage3. Of course, you will also want
+to modify the <c>subarch</c> setting in your stage3 spec to match what you used
+in your stage2 spec.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>I want to build a bunch of stages for various subarches. How should I
+do this?</title>
+<body>
+
+<p>
+First, build a generic stage1. Then use this stage1 to build a specialized
+stage2 and stage3. Use the stage1 again to build another specialized stage2 and
+stage3. You do not need to re-build the stage1 -- all your specialized stage2's
+and stage3's can use the same "seed" stage1.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Can I build a stage1 for a non-generic CPU type?</title>
+<body>
+
+<p>
+This is a very bad idea, as users expect stage1's to work on any type of
+subarchitecture. This way, they can use the stage1 on any system without
+worries. You should be sure to not "pollute" your stage1 with non-generic
+CPU-specific code. Always use a "generic" stage3 as a seed to build a new
+stage1.
+</p>
+
+</body>
</section>
+
+<section>
+<title>I thought that catalyst was able to build stages "from scratch." If
+catalyst builds stages from scratch, then why does it need a "seed
+stage"?</title>
+<body>
+
+<p>
+Good question. As you know, a stage2 and stage3 are dependent on previous
+stages for building, which is expected and made clear by their name (ie. a
+"stage2" implies that there was a "stage1".) However, catalyst does need a
+seed stage for building a stage1, so in regards to building a stage1 it's worth
+looking into why this is necessary. When building a stage1, catalyst uses the
+seed stage3 to set up a chroot environment. Inside the chroot environment, the
+new stage1 is built by setting the <c>ROOT</c> environment variable to
+<path>/tmp/stage1root</path>. This instructs the package manager to merge all
+new packages not to the current filesystem, but to the filesystem in
+<path>/tmp/stage1root</path>. Catalyst then tars up <path>/tmp/stage1root</path>
+and it becomes the target stage1. What this means is that when catalyst builds
+a stage1, the stage1 itself does not inherit any binaries or libraries from the
+seed that is used. The seed that is used <e>does</e> impact the target stage1
+somewhat -- the Linux headers on the seed are used for building the stage1's
+glibc, and the compilers on the seed are used to compile all the programs on
+the stage1. The seed stage is used to isolate the stage1 build process from
+your local system, and also allows for x86 stage1's to be built on amd64
+systems, for example.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Is there an official HOWTO for Catalyst?</title>
+<body>
+
+<p>
+Currently, there is no official HOWTO. If you are interested in writing one,
+though, please file a bug with the HOWTO attached to it. The lack of an
+official HOWTO does not mean that catalyst is completely undocumented, though.
+When catalyst is emerged, a well commented set of example spec files are
+installed to <path>/usr/share/doc/catalyst-$version/examples</path>.
+</p>
+<p>
+If you still have questions after reading through the examples, feel
+free to subscribe to the gentoo-catalyst mailing list.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Where do I put per-package use flags, mask settings, etc.?</title>
+<body>
+
+<p>
+Catalyst supports the configuration files in /etc/portage. Just add the
+following to your spec file, and make sure that you use the same
+<c>portage_confdir</c> setting for your seed stages as well:
+</p>
+<p>
+portage_confdir: /path/to/custom/etc/portage
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Should I really build my own stage1 or just use one from a Gentoo
+mirror?</title>
+<body>
+
+<p>
+It is best practice to <b>always</b> build your own stages if you are not using
+the same snapshot that was used to build the last release. The state of the tree
+is very much dependent on itself. If you have a stage1 from 3 months ago, it is
+very likely that you will run into problems with blockers and other changes in
+the tree that will cause you build or compatibility problems.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>How do I keep my GRP/stages/LiveCD packages updated?</title>
+<body>
+
+<p>
+Catalyst uses Portage for all of the building work, so all that you have to do
+is regenerate your Portage snapshot and rebuild your GRP/stages/LiveCD. Portage
+will follow all of its normal rules for deciding which packages to update.
+</p>
+
+</body>
+</section>
+
+<section>
+<title>Does Catalyst use any special USE flag syntax?</title>
+<body>
+
+<p>
+No, catalyst's USE flag syntax is exactly the same as portage's.
+</p>
+
+</body>
+</section>
+
</chapter>
</guide>
--
gentoo-commits@g.o mailing list
|
