1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
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"
PYTHON_TARGETS="python2_7"
PYTHON_MULTILIB_TARGETS_PYTHON2_7_X86="32 64"
PYTHON_SINGLE_TARGET="python2_7"
PYTHON_MULTILIB_SINGLE_TARGETS_PYTHON2_7_X86="32 64"
ABI_X86="64 32" # I put have x32 in here and elsewhere too but had to re-bootstrap glibc to make it work... gl!
--
then run 'eselect profile set "gmt:default/linux/amd64/13.0/developer/multilibpython"'
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:
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.
If you are bootstrapping in to a triple-multilib environment with x32 as well,
you'll need to hack on glibc to bootstrap the multilib process. The trick
is to bootstrap with crossdev and wedge your crossdev compiler into the
glibc Makefiles after the ebuild crashes, and then restart... well it took a few
more tricks than that actually... but that will get you started.
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.
|
GitWeb