Backported two more patches

*3d1b78fc328fc1800dc16aebfbafab71a919a291
*cd49a343f29f094fd6031a4661b8aa67274dc775

2 files changed, 22 insertions, 9 deletions

diff --git a/content/ebuild-writing/variables.xmli b/content/ebuild-writing/variables.xmli
index eb60624..9a6ddf5 100644
--- a/content/ebuild-writing/variables.xmli
+++ b/content/ebuild-writing/variables.xmli
@@ -333,21 +333,28 @@ SRC_URI="http://example.com/files/${P}-core.tar.bz2
     <title>Version Formatting Issues</title>
     
     <para>
-      Often upstream's tarball versioning format doesn't quite follow Gentoo conventions. Differences in how underscores
-      and hyphens are used are particularly common. For example, what Gentoo calls <package>foo-1.2.3b</package> may
-      be expecting a tarball named <filename>foo-1.2-3b.tar.bz2</filename>. Rather than hard coding version numbers, it
-      is preferable to make a <varname>MY_PV</varname> variable and use that. The easy way to do this, which should be
-      used unless you are sure you know what you are doing, is to use <filename>versionator.eclass</filename>:
+    Often upstream's tarball versioning or naming format doesn't quite follow
+    Gentoo conventions. Using capital letters in names or differences in how
+    underscores and hyphens are used in versions are particularly common. 
+    For example, what Gentoo calls <command>foo-1.2.3b</command> may be
+    expecting a tarball named <command>Foo-1.2-3b.tar.bz2</command>. 
+    Rather than hard   coding the package string, 
+    it is preferable to make <command>MY_PN</command>, <command>MY_PV</command> and <command>MY_P</command>
+    variables and use those to define the upstream naming. 
+    The easy way of redefining the version, which should be
+    used unless you are sure you know what you are doing, is to use the <command>versionator</command> eclass:
     </para>
 
     <programlisting language="ebuild"><![CDATA[
 inherit versionator
+MY_PN="Foo"
 MY_PV=$(replace_version_separator 2 '-')
+MY_P="${MY_PN}-${MY_PV}"
 ]]></programlisting>
 
     <para>
       This code has the advantage that it will carry on working even if upstream switches to a format like
-      <filename>foo-1.3-4.5.tar.bz2</filename> (yes, this really happens).
+      <command>Foo-1.3-4.5.tar.bz2</command> (yes, this really happens).
     </para>
 
     <para>
diff --git a/content/general-concepts/dependencies.xmli b/content/general-concepts/dependencies.xmli
index 271e6e5..a654f02 100644
--- a/content/general-concepts/dependencies.xmli
+++ b/content/general-concepts/dependencies.xmli
@@ -58,9 +58,15 @@
 
     <para>
       All packages have an implicit compile-time and runtime dependency upon the entire <literal>system</literal>
-      target. It is therefore not necessary, nor advisable, to specify dependencies upon <package>gcc</package>,
-      <package>libc</package> and so on, except where specific versions or packages (for example,
-      <package>glibc</package> over <package>uclibc</package>) are required.
+      target. It is therefore not necessary, nor advisable, to
+      specify dependencies upon toolchain packages like <command>gcc</command>, <command>libc</command>
+    and so on, except where specific versions or packages (for example,
+    <command>glibc</command> over <command>uclibc</command>) are required.  Note that this rule also needs consideration for packages like <command>flex</command>, <command>zlib</command> and <command>libtool</command>, which
+    aren't in the <command>system</command> target for every profile. 
+    For example, the embedded profile doesn't have <command>zlib</command> 
+    in <command>system</command> target, the <command>libtool</command> ABI 
+    might change and break building order and <command>flex</command> might 
+    get removed from the<command>system</command> target in future.
     </para>
 
     <para>