Gentoo Archives: gentoo-portage-dev

From: Kumba <kumba@g.o>
To: gentoo-portage-dev@l.g.o
Subject: Re: [gentoo-portage-dev] biarch support for portage-ng?
Date: Mon, 31 May 2004 05:51:36
Message-Id: 40BAC88A.9080902@gentoo.org
In Reply to: [gentoo-portage-dev] biarch support for portage-ng? by Andy Lutomirski
1 Andy Lutomirski wrote:
2
3 > (I may be misguided in some of this because I've never actually used
4 > Gentoo.)
5 >
6 > I plan on switching Gentoo soon on my AMD64 machine. I haven't yet
7 > found a distro that handled 32-bit compatibility well (debian's way just
8 > sounds pointless, fedora fails miserably, SuSE is decent), but it seems
9 > like Gentoo has the potential to do very well. Here's an idea:
10 >
11 > For each ebuild (slot), portage would allow multiple architectures to be
12 > "installed." One would be "master" -- this works normally. Everything
13 > thereafter would be a "compat" install or something -- only libraries
14 > (that is, files that do not exist in the master) would get installed.
15 >
16 > So:
17 >
18 > foo - AMD64 (master) installs /usr/bin/foo, /etc/foo.conf, and
19 > /usr/lib64/libfoo.so
20 > foo - x86 (compat) installs only /usr/lib/libfoo.so
21 >
22 > Then packages should by default depend on their own arch's version.
23 > Furthermore, a "default" arch should be selectable, so that, if amd64
24 > was default, x86's gtk would depend on amd64's gtk, and amd64's would be
25 > installed as master. A tool to switch from x86 master to amd64 master
26 > (by remerging both) would be nice, as ebuilds will be gradually fixed to
27 > work on amd64.
28 >
29 > Some provision for arch-independant ebuilds would also help.
30 >
31 >
32 > With a feature like this, I want to be able to do:
33 > # emerge --arch x86 gtk
34 >
35 > so that I can run some 32-bit binary. I then want
36 > # emerge --arch amd64 --master gtk
37 > to build the amd64 version and replace any executables that the x86
38 > build may have installed, so x86 becomes the slave.
39 >
40 > Is something like this reasonable?
41 >
42 > --Andy
43
44 You've basically described a hybrid form of multi-slot/multilib features
45 several of the arch teams and embedded team hope for in portage itself
46 (not portage-ng, whose status I think is MIA until some real code starts
47 getting produced).
48
49 Multi-slot is a feature to allow for toolchains capable of multiple
50 archs to be merged on a given arch -- a.k.a. cross-compliler support.
51
52 Multilib is a feature several archs want to allow for things like mixed
53 32bit/64bit userlands. amd64 can use this to have apps be built at
54 32bit or 64bit. Others like mips can use this for the o32/n32/n64
55 userland, or sparc for 32/64 bit, and so on.
56
57 When it'll get implemented, hard to say. It at minimum requires a
58 re-write of portage's backend database (how it stores stuff in
59 /var/db/pkg), the progress of which I am unsure of.
60
61
62 --Kumba
63
64 --
65 "Such is oft the course of deeds that move the wheels of the world:
66 small hands do them because they must, while the eyes of the great are
67 elsewhere." --Elrond
68
69 --
70 gentoo-portage-dev@g.o mailing list