Add readme file

1 files changed, 109 insertions, 0 deletions

diff --git a/README b/README
new file mode 100644
index 0000000..31ca9af
--- /dev/null
+++ b/README
@@ -0,0 +1,109 @@
+WARNING: Don't use this overlay if you value your sanity or your
+gentoo installation!
+
+WARNING: Don't ignore the above warning!
+This is seriously not ready for sane people yet.
+
+"But," you say, "I am batshit /in/sane, and my ~amd64 multilib Gentoo
+currently works far too well.  Pretty please, isn't there some way you
+could seriously fuck it up for me?  Ideally, I'd like to be forced to
+boot from a rescue CD and deploy the disaster-recovery tarballs."
+
+In that case, my friend, you've come to the right place!
+
+Although it may not stay that way, for now this overlay contains mostly
+my work-in-progress attempt to port lots and lots of ebuilds to support
+ABI-expand multilib.  This includes a pretty scary number of overriden
+core eclasses.
+
+Some of this is ready to go upstream.  Most isn't.  Like I said,
+it's a work in progress.
+
+To activate this, you'll need to install the overlay and then
+hack up your /etc/portage/repos.conf like so:
+
+--
+[DEFAULT]
+eclass-overrides = gmt
+main-repo = gentoo
+
+[gmt]
+priority=0
+--
+
+if you use this overlay without the eclass overrides, I can confidently
+assure you, some horrible shit is going to happen.  If you're gonna
+use it, use the eclass override.
+
+If you have a local overlay that you want to take precedent over gmt,
+you should put that in your repos.conf, with a "priority" setting
+lower than that of "gmt".  Use emerge --info --verbose to ensure that
+portage is ordering your overlays that way you want it to.
+
+Before you even start using this, you should remove it from your
+layman, and get yourself on a multilib amd64 profile, with
+ACCEPT_KEYWORDS="~amd64", sync your portage,
+and get your packages completely consisitent, such that
+
+  # emerge -DupvN '@world'
+
+and 
+
+  # emerge --depclean
+
+and
+
+  # emerge '@preserved-rebuild'
+
+and
+
+  # revdep-rebuild
+
+all say there's nothing to do.
+
+Now that you're ready to break everything, you'll want to add my overlay
+back in, make the aformentioned changes to /etc/portage/repos.conf, and
+have the following in /etc/portage/make.conf (not precisely -- you'll want
+these in addition to whatever other stuff belongs there):
+
+--
+USE_PYTHON="2.7" # it's OK to have additional python's in there but 2.7 is required
+PYTHON_TARGETS="python2_7" # likewise
+PYTHON_SINGLE_TARGET="python2_7"
+ABI_X86="64 32" # It might work to put other stuff in there, but this is what I have
+--
+
+Now you will find that you are fucked.  Congratulations!
+
+Portage will almost always complain that something is wrong no matter what
+you try to do.  That's because, as I mentioned a couple times, this is a
+work in progress.
+
+But, if you start at the bottom of your dependency tree, and slowly work
+your way up, you might be able to get some stuff working again.  Over time,
+with any luck, things will become less fucked as I continue my work.
+
+Notes:
+
+Python 2.7 contains some very agressive, bad hacks.  This will need to be completely
+reworked before it's useful, but it's got just enough in there to make things
+mostly work relative to what I have implemented so far.
+
+Python is the hardest part of the multi-abi puzzle, imo.  I will get back to it soon,
+hopefully with some less agressive hacks.  For now, well, it does compile on my box
+however YMMV.
+
+If you are migrating from a normal multilib system to an ABI_X86-based system with
+this overlay, you're going to get caught in an circular-dependencies mess regarding
+gobject-introspection, dbus, glib, pango, and cairo.  My only advice, for now,
+is to keep fiddling around and forcing things to build with "USE=-blah ebuild" until that
+little gordian-dependency-knot unravels.  Once that occurs, you'll still have
+an inconsistent package database but you'll be able to go much further with things.
+
+You will probably have lots of collisions until you emerge the version of
+app-emulation/emul-linux-x86-baselibs from my overlay.  Either force them or
+emerge app-emulation/emul-linux-x86-baselibs first.  The way I did it was
+simply to remove app-emulation/emul-linux-x86-* entirely, and rely on '@preserved-rebuild'
+to pick up the slack.  Thus far, I don't think I've had to put any other
+emul-linux-x86-* stuff back in except for baselibs, xlibs and opengl, the
+latter two being empty placeholders.