From: Enrico Weigelt <weigelt@metux.de>
To: gentoo-user@lists.gentoo.org
Subject: Re: [gentoo-user] Re: emerge 32bits on 64bits platform
Date: Fri, 20 Aug 2010 17:56:05 +0200 [thread overview]
Message-ID: <20100820155605.GA21342@nibiru.local> (raw)
In-Reply-To: <i4hq6v$13p$1@dough.gmane.org>
* Nikos Chantziaras <realnc@arcor.de> wrote:
> Welcome to hell. No, that's possible, as others pointed out. There was
> an initiative to bring true multilib to Gentoo a year or so back (maybe
> more) but it seems it died and no one's working on it.
>
> For your browser this is probably not so problematic. But imagine
> someone running the latest graphics stack (libdrm, mesa, etc.) on his
> 64bit machine, but its totally useless because proprietary Linux games
> are 32bit and thus won't run.
The problem here is that this essentially means having two systems
in one, 32bit and a 64bit one. To make it really clean, we'd actually
need two separate installations (eg. using jails). But that makes
administration quite complex.
Perhaps portage could be extended to support a concept of subsystems,
which are fully self-conftained for the runtime stuff only (but no
portage, toolchains, etc). Everything that's not required for booting
and building (so, the essential base-packages) is now sitting within
a subsystem (maybe that's even a jail). Each subsystem of course
also has its own /var/db/pkg etc (maybe even own /etc/portage stuff).
Portage would now compute an internal portage tree for all subsystems
using namespaces. The actual build then runs in an sysroot environment
for the actual subsystem.
Let's take an example: mc
On an fresh system, `emerge -peqt app-misc/mc` looks like this:
[ebuild N ] app-misc/mc-4.7.0.3 USE="edit gpm -X -nls -samba -slang"
[ebuild N ] sys-libs/gpm-1.20.5 USE="(-selinux)"
[ebuild N ] app-arch/xz-utils-4.999.9_beta USE="threads -nls -static-libs"
[ebuild N ] dev-libs/glib-2.24.1-r1 USE="-debug -doc -fam -hardened (-selinux) -xattr"
[ebuild N ] sys-devel/gettext-0.17-r1 USE="-acl -doc -emacs -nls -nocxx -openmp"
[ebuild N ] dev-util/gtk-doc-am-1.15
[ebuild N ] app-text/docbook-xml-dtd-4.3-r1
[ebuild N ] dev-libs/libxslt-1.1.26 USE="-crypt -debug -python"
[ebuild N ] dev-libs/libxml2-2.7.7 USE="-debug -doc -examples -ipv6 -python -readline -test"
[nomerge ] app-text/docbook-xml-dtd-4.3-r1
[ebuild N ] app-text/sgml-common-0.6.3-r5
[ebuild N ] app-arch/unzip-6.0-r1 USE="bzip2 -unicode"
[nomerge ] app-misc/mc-4.7.0.3 USE="edit gpm -X -nls -samba -slang"
[ebuild N ] dev-util/pkgconfig-0.25-r2 USE="-hardened"
[nomerge ] app-text/docbook-xml-dtd-4.3-r1
[ebuild N ] app-text/docbook-xsl-stylesheets-1.75.2
[ebuild N ] app-text/build-docbook-catalog-1.4
Now on the new model it would be: `emerge -peqt x86_32::app-misc/mc`
[ebuild N ] x86_32::app-misc/mc-4.7.0.3 USE="edit gpm -X -nls -samba -slang"
[ebuild N ] x86_32::sys-libs/gpm-1.20.5 USE="(-selinux)"
[ebuild N ] main::app-arch/xz-utils-4.999.9_beta USE="threads -nls -static-libs"
[ebuild N ] x86_32::dev-libs/glib-2.24.1-r1 USE="-debug -doc -fam -hardened (-selinux) -xattr"
[ebuild N ] main::sys-devel/gettext-0.17-r1 USE="-acl -doc -emacs -nls -nocxx -openmp"
[ebuild N ] x86_32::sys-devel/gettext-0.17-r1 USE="-acl -doc -emacs -nls -nocxx -openmp"
[ebuild N ] x86_32::dev-util/gtk-doc-am-1.15
[ebuild N ] main::app-text/docbook-xml-dtd-4.3-r1
[ebuild N ] x86_32::dev-libs/libxslt-1.1.26 USE="-crypt -debug -python"
[ebuild N ] x86_32::dev-libs/libxml2-2.7.7 USE="-debug -doc -examples -ipv6 -python -readline -test"
[nomerge ] main::app-text/docbook-xml-dtd-4.3-r1
[ebuild N ] main::app-text/sgml-common-0.6.3-r5
[ebuild N ] main::app-arch/unzip-6.0-r1 USE="bzip2 -unicode"
[nomerge ] x86_32::app-misc/mc-4.7.0.3 USE="edit gpm -X -nls -samba -slang"
[ebuild N ] main::dev-util/pkgconfig-0.25-r2 USE="-hardened"
[nomerge ] main::app-text/docbook-xml-dtd-4.3-r1
[ebuild N ] main::app-text/docbook-xsl-stylesheets-1.75.2
[ebuild N ] main::app-text/build-docbook-catalog-1.4
Note that here portage into which subsystem a package has to go in.
That's done by a new kind of depdendencies: buildtool. So a plain system
(w/o subsystems at all), these simply would be silently added to $DEPEND
(prefixed w/ "main::").
Of course, this requires all packages to be fully crosscompilable
in sysroot, and here's yet some work to do (essentially, that's what
oss-qm is doing all the day ;-p).
Ah, and this approach can also supersede crossdev (at least most of it)
and provide a fine tool for managing tiny containers which don't need
their own toolchain and portage stuff.
cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/
phone: +49 36207 519931 email: weigelt@metux.de
mobile: +49 151 27565287 icq: 210169427 skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------
prev parent reply other threads:[~2010-08-20 16:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-16 18:13 [gentoo-user] emerge 32bits on 64bits platform Stéphane Guedon
2010-08-16 19:39 ` Johannes Kimmel
2010-08-16 19:47 ` Stéphane Guedon
2010-08-16 20:32 ` Bill Longman
2010-08-17 7:24 ` Jesús J. Guerrero Botella
2010-08-17 8:13 ` Alan McKinnon
2010-08-17 13:43 ` Mike Edenfield
2010-08-17 19:24 ` Bill Longman
2010-08-18 14:52 ` Stéphane Guedon
2010-08-18 23:26 ` [gentoo-user] " Nikos Chantziaras
2010-08-20 15:56 ` Enrico Weigelt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100820155605.GA21342@nibiru.local \
--to=weigelt@metux.de \
--cc=gentoo-user@lists.gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox