[gentoo-commits] gentoo commit in xml/htdocs/proj/en/gentoo-alt/prefix: bootstrap-solaris.xml

[Fabian Groffen (grobian)]

grobian     08/02/21 17:13:57

  Modified:             bootstrap-solaris.xml
  Log:
  Update the Solaris bootstrap guide into a working one

Revision  Changes    Path
1.22                 xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml

file : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml?rev=1.22&view=markup
plain: http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml?rev=1.22&content-type=text/plain
diff : http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml?r1=1.21&r2=1.22

Index: bootstrap-solaris.xml
===================================================================
RCS file: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml,v
retrieving revision 1.21
retrieving revision 1.22
diff -u -r1.21 -r1.22
--- bootstrap-solaris.xml	9 Jan 2008 18:27:45 -0000	1.21
+++ bootstrap-solaris.xml	21 Feb 2008 17:13:56 -0000	1.22
@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="UTF-8"?>
 <!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
-<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml,v 1.21 2008/01/09 18:27:45 grobian Exp $ -->
+<!-- $Header: /var/cvsroot/gentoo/xml/htdocs/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml,v 1.22 2008/02/21 17:13:56 grobian Exp $ -->
 
 <guide link="/proj/en/gentoo-alt/prefix/bootstrap-solaris.xml" lang="en">
   <title>Gentoo Prefixed Portage Bootstrap Process for Solaris</title>
@@ -19,8 +19,8 @@
   <!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
   <license/>
 
-  <version>1.5</version>
-  <date>2008-01-09</date>
+  <version>1.6</version>
+  <date>2008-02-21</date>
 
   <chapter>
     <title>Bootstrapping on Solaris 10</title>
@@ -40,7 +40,8 @@
           "Spartan" platforms to bootstrap on, and for sure not as easy
           as for instance a Linux distribution or Mac OS X.  However,
           don't despair when things go wrong, it's just known to be
-          hard(er), but not impossible.
+          hard(er), but not impossible.  Feel free to ask in the
+          <c>gentoo-alt</c> IRC channel, or mailing list.
         </p>
       </body>
     </section><!-- }}} -->
@@ -60,8 +61,8 @@
         </note>
         <p>
           The first step is to choose a path to install into.  We refer
-          to this path as "prefix path", stored in the variable
-          <c>EPREFIX</c>.  Some suggestion for your prefix path is
+          to this path as "Prefix path", stored in the variable
+          <c>EPREFIX</c>.  Some suggestion for your Prefix path is
           <path>$HOME/gentoo</path>.
           Whatever you chose, make sure you set it in your environment:
         </p>
@@ -73,7 +74,7 @@
           instead.
         </note>
         <p>
-          Next, add the following paths in your soon to be prefix to
+          Next, add the following paths in your soon to be Prefix to
           your <c>PATH</c> environment.
           <path>$EPREFIX/bin</path>,
           <path>$EPREFIX/usr/bin</path>,
@@ -87,7 +88,7 @@
           <path>/usr/sfw/i386-sun-solaris2.10/bin</path>,
           <path>/usr/bin</path> and <path>/bin</path>.
         </p>
-        <pre caption="Add prefix and utility paths to your PATH">
+        <pre caption="Add Prefix and utility paths to your PATH">
 $ <i>export PATH="$EPREFIX/usr/bin:$EPREFIX/bin:$EPREFIX/tmp/usr/bin:$EPREFIX/tmp/bin:/usr/sfw/bin:/usr/sfw/i386-sun-solaris2.10/bin:/usr/bin:/bin"</i>
         </pre>
         <note>Solaris 10/Sparc users need
@@ -142,15 +143,17 @@
           many errors and warnings you might see during emerging.
         </p>
         <pre caption="emerge sed">
-$ <i>emerge --oneshot "=sys-apps/sed-4.1.4*"</i>
+$ <i>emerge --oneshot sed</i>
         </pre>
         <p>
-          Next, we emerge the <c>bash</c> shell and its dependency
-          ncurses.  <c>bash</c> is used extensively within portage and
-          other applications.
+          Next, we emerge the <c>bash</c> shell Portage heavily relies
+          on.  The same holds for <c>wget</c>, the download manager.
+          Since its dependencies cannot be compiled at this stage,
+          we ignore those for the moment.
         </p>
-        <pre caption="emerge bash">
-$ <i>emerge --oneshot bash</i>
+        <pre caption="emerge bash and wget">
+$ <i>emerge --oneshot "&lt;bash-3.2_p33"</i>
+$ <i>emerge --oneshot --nodeps wget</i>
         </pre>
         <note>
           It is safe to ignore the "1 config files in XXX need updating"
@@ -159,120 +162,67 @@
         <p>
           Now, we will emerge a compiler which will use the gnu linker.
           This is a requirement for many packages that follow in the
-          bootstrap process.  The gcc compiler shipped by Sun uses the
-          Solaris native linker, which is as "Spartan" as the whole
-          system.  The packages to emerge include the <c>baselayout</c>
-          package.  Some, if not many, scripts and tools within a Gentoo
-          system assume the availability of the <c>baselayout</c>
-          package for all communication using the Gentoo colour scheme.
+          bootstrap process, in particular Perl.  The gcc compiler
+          shipped by Sun uses the Solaris native linker, which is as
+          "Spartan" as the whole system.  The packages to emerge include
+          the <c>baselayout</c> package.  Some, if not many, scripts and
+          tools within a Gentoo system assume the availability of the
+          <c>baselayout</c> package for all communication using the
+          Gentoo colour scheme.
         </p>
         <pre caption="emerge linker and compiler">
-$ <i>emerge --oneshot --nodeps sys-devel/m4</i>
-$ <i>emerge --oneshot --nodeps sys-apps/baselayout-prefix</i>
-$ <i>emerge --oneshot --nodeps sys-devel/flex</i>
-$ <i>emerge --oneshot --nodeps sys-devel/binutils-config</i>
-$ <i>emerge --oneshot --nodeps sys-devel/binutils</i>
-$ <i>emerge --oneshot --nodeps sys-devel/gcc-config</i>
-$ <i>emerge --oneshot --nodeps sys-devel/gcc</i>
-        </pre>
-        <p>
-          We continue getting some autotools stuff into our prefix.
-        </p>
-        <pre caption="emerge autotools">
-$ <i>emerge --oneshot --nodeps "=autoconf-2.1*" "=autoconf-2.6*" "autoconf-wrapper"</i>
-$ <i>emerge --oneshot --nodeps "=automake-1.4*" "=automake-1.5*" "=automake-1.6*" "=automake-1.7*" "=automake-1.8*" "automake-wrapper"</i>
-        </pre>
-        <note><c>>=automake-1.9</c> and <c>libtool</c> are not (yet)
-          installed at this stage.</note>
-        <p>
-          Next, we have to get some tools in order to finalise getting
-          the autotools in our prefix.  Because we installed <c>wget</c>
-          in a temporary location, let's not forget to install it
-          properly by emerging it now:
-        </p>
-        <pre caption="emerge wget">
-$ <i>env USE="-ssl" emerge --oneshot --nodeps wget</i>
-        </pre>
-        <p>
-          After this we can emerge texinfo, which <c>automake-1.9</c>
-          needs.
-        </p>
-        <pre caption="emerge texinfo">
-$ <i>emerge --oneshot --nodeps help2man texinfo</i>
-        </pre>
-        <p>
-          Now we can finish installing the autotools:
-        </p>
-        <pre caption="finalise emerge autotools">
-$ <i>emerge --oneshot --nodeps "=automake-1.9*" "=automake-1.10*"</i>
-$ <i>emerge --oneshot --nodeps libtool</i>
-        </pre>
-        <p>
-          Now we have some decent autotooling stuff around, we can get
-          some decent core utilities in our prefix.  First we have to
-          upgrade to a newer binutils though, or we may encounter
-          "multiply defined symbols" on sparcv9 systems.
-        </p>
-        <pre caption="emerge coreutils">
-$ <i>emerge --oneshot --nodeps sys-devel/binutils</i>
-$ <i>emerge --oneshot --nodeps sys-apps/coreutils</i>
-        </pre>
-        <p>
-          Same goes for GNU patch.
-        </p>
-        <pre caption="emerge patch">
-$ <i>emerge --oneshot patch</i>
-        </pre>
-        <p>
-          Finally we emerge python and some other utilities in our
-          prefix.  These are the remaining packages that we temporarily
-          installed to bootstrap our system.
-        </p>
-        <pre caption="emerge remaining temporarily installed packages">
-$ <i>emerge --oneshot --nodeps python</i>
-$ <i>emerge --oneshot --nodeps findutils</i>
-$ <i>emerge --oneshot --nodeps tar</i>
-$ <i>emerge --oneshot --nodeps grep</i>
-$ <i>emerge --oneshot --nodeps make</i>
-$ <i>emerge --oneshot --nodeps bison</i>
+$ <i>emerge --oneshot m4</i>
+$ <i>emerge --oneshot --nodeps baselayout-prefix</i>
+$ <i>emerge --oneshot --nodeps flex</i>
+$ <i>emerge --oneshot --nodeps binutils-config</i>
+$ <i>emerge --oneshot --nodeps binutils</i>
+$ <i>emerge --oneshot --nodeps gcc-config</i>
+$ <i>emerge --oneshot --nodeps gcc</i>
+        </pre>
+        <p>
+          We continue getting more tools in our Prefix.  We no longer
+          ignore dependencies, so a lot of packages will be emerged at
+          this stage.  Slowly our Prefix gets more robust as we progress
+          here.
+        </p>
+        <pre caption="emerge several tools">
+$ <i>emerge --oneshot coreutils</i>
+$ <i>emerge --oneshot findutils</i>
+$ <i>emerge --oneshot tar</i>
+$ <i>emerge --oneshot grep</i>
 $ <i>emerge --oneshot gawk</i>
+$ <i>emerge --oneshot patch</i>
+$ <i>emerge --oneshot make</i>
         </pre>
         <p>
-          Before we continue to emerge all ebuilds from <c>system</c>,
-          we first install <c>portage</c>.  We need to overwrite the
-          version that was installed by the bootstrap script.
-          Installing a new portage will make sure it uses the tools
-          provided by the prefix, and forget about the temporary
-          installed tools.
+          Now we have a good bunch of programs that Portage needs, we
+          can replace the bootstrapped Portage by a properly installed
+          one, using portage itself.  Also here a few dependencies are
+          first emerged, such as the language Portage is written in:
+          <c>python</c>.  We need to temporarily tell Portage that the
+          bootstrapped Portage can be overwritten.
         </p>
         <pre caption="emerge portage">
-$ <i>env FEATURES="-collision-protect" emerge --oneshot --nodeps portage</i>
+$ <i>env FEATURES="-collision-protect" emerge --oneshot portage</i>
         </pre>
         <p>
-          Now we're about to start the big work, we remove the temporary
-          directory and its use as we got it all in our prefix now.
+          Now we have emerged everything we bootstrapped before, we
+          remove the temporary directory and its use as it is no longer
+          necessary.
         </p>
         <pre caption="remove tmp directory">
 $ <i>rm -Rf $EPREFIX/tmp/*</i>
 $ <i>hash -r</i>
         </pre>
         <p>
-          Next, we do the real work where all packages get reemerged in
-          such an order that they make use of packages in the prefix
-          itself.
+          Before we do any further merges, we are going to update our
+          tree.  Since snapshots in Prefix are actually (anonymous) SVN
+          checkouts of the tree, we need <c>subversion</c> to update it.
         </p>
-        <pre caption="emerge system">
-$ <i>env USE="berkdb" emerge -e system</i>
+        <pre caption="emerge subversion">
+$ <i>emerge --oneshot subversion</i>
         </pre>
         <p>
-          This will happily install a lot of stuff and reinstall what
-          you emerged before.  This is necessary to avoid compilation
-          failures due to dependencies.
-        </p>
-        <p>
-          We can now update the tree.  Since snapshots now are actually
-          (anonymous) SVN checkouts of the tree, we can immediately use
-          SVN commands on the tree instead of checking a tree out first.
           Because Portage knows how to deal with the SVN tree, and the
           bootstrap script has set a correct <c>SYNC</c> variable in
           your <path>etc/make.conf</path>, updating the tree is done
@@ -282,25 +232,33 @@
 $ <i>emerge --sync</i>
         </pre>
         <p>
-          To really do this properly, after emerging <c>system</c>, one
-          should re-emerge <c>system</c>, because now all packages can
-          be compiled with all tools from the prefix, instead of based
-          on tools in the system root.  Before you do though, this is
-          the good time to set your general <c>USE</c>-flags, such as
-          <c>nls</c> to get localised messages in
-          <path>$EPREFIX/etc/make.conf</path>.  In that file, you
-          can also set <c>CFLAGS</c> for your compilation.  Be
-          conservative with <c>CFLAGS</c>!  Note that the code below is
-          an example, and is meant for inspiration only.
+          Next, we let Portage emerge all packages that complete a
+          system install that we eventually need to finalise this Prefix
+          installation.
+        </p>
+        <pre caption="emerge system">
+$ <i>emerge -u system</i>
+        </pre>
+        <p>
+          Now is a good time to set the preferences for our soon to be
+          Prefix.  This includes customisations such as general
+          <c>USE</c>-flags, <c>CFLAGS</c> and <c>MAKEOPTS</c> in
+          <path>$EPREFIX/etc/make.conf</path>.  Be conservative with
+          <c>CFLAGS</c>!  Note that the code below is an example, and is
+          meant for inspiration only.
         </p>
-        <pre caption="Customising the prefix installation - example">
+        <pre caption="Customising the Prefix installation - example">
 $ <i>echo 'USE="unicode nls"' >> $EPREFIX/etc/make.conf</i>
 $ <i>echo 'CFLAGS="-O2 -pipe"' >> $EPREFIX/etc/make.conf</i>
 $ <i>echo 'CXXFLAGS="${CFLAGS}"' >> $EPREFIX/etc/make.conf</i>
         </pre>
         <p>
-          Since we're about to rebuild our system for the last time, we
-          can unset all hacks we made to help the bootstrap process.
+          Since we have everything in place for a self-catered rebuild,
+          we can unset all hacks we made to help the bootstrap process,
+          and start the final stage to install the Prefix system.  This
+          final stage recompiles everything in the system, but now all
+          packages can be compiled with tools from the Prefix, instead
+          of those from the host system.
         </p>
         <pre caption="Unsetting LDFLAGS and CPPFLAGS variables">
 $ <i>unset LDFLAGS</i>
@@ -312,9 +270,9 @@
           <c>CPPFLAGS</c>.
         </note>
         <p>
-          After <c>system</c> has emerged successfully, your prefix will
+          After <c>system</c> has emerged successfully, your Prefix will
           be set up properly, and you can emerge the whichever tools you
-          choose from the prefix tree.
+          choose from the Prefix tree.
         </p>
       </body>
     </section><!-- }}} -->
@@ -323,8 +281,8 @@
       <title>Using the Prefix</title>
       <body>
         <p>
-          To use your bootstrapped prefix environment, you best start a
-          shell from the prefix, such that your path and other
+          To use your bootstrapped Prefix environment, you best start a
+          shell from the Prefix, such that your path and other
           environment variables are set correctly.  To facilitate in
           this, a small helper script can be created by the bootstrap
           script.
@@ -337,8 +295,8 @@
           After running this, a script <c>startprefix</c> will be
           present in <c>$EPREFIX</c>.  You can freely move the script to
           e.g. your homedir for convenience.  Running the script will
-          drop you into a prefix shell, where for example <c>emerge</c>
-          is directly at your disposal.  Enjoy your prefix!
+          drop you into a Prefix shell, where for example <c>emerge</c>
+          is directly at your disposal.  Enjoy your Prefix!
         </p>
       </body>
     </section>



-- 
gentoo-commits@l.g.o mailing list