On 11/28/05, Harm Geerts <[EMAIL PROTECTED]> wrote:
> On Tuesday 29 November 2005 01:23, Mark Knecht wrote:
> > On another list, music based, I was told by someone that using both
> > ~x86 and ~AMD64 on the same system is incorrect by design. I have no
> > reason to not believe him but I seem to have missed this point when I
> > was building this system.
> >
> > Can someone clarify if this is the case? If so, what is the
> > recommended action for me to take at this point?
>
> It depends on the profile you are currently using.
>
> # ls -l /etc/make.profile
> lrwxrwxrwx  1 root root 50 mei 11  2005 /etc/make.profile
> -> ../usr/portage/profiles/default-linux/amd64/2005.0
>
> As you can see my system is using the amd64 profile version 2005.0
> That gives ACCEPT_KEYWORDS a default value of "amd64"
> If I want to run packages marked unstable for amd64 I would change the
> ACCEPT_KEYWORDS value to "~amd64" in /etc/make.conf
>
> ACCEPT_KEYWORDS decides which package versions portage should use when merging
> something.
> Each ebuild has a KEYWORDS variable, it lists all the arches that can use that
> version of a package.
>
> So by setting ACCEPT_KEYWORDS="~x86" on a amd64 profile you might install
> packages that are only tested for ~x86. This can lead to serious problems
> with packages that are broken on amd64 (and therefore not keyworded as amd64)
>
> You should set ACCEPT_KEYWORDS to the correct value for your profile.
> Then run the following to make sure all installed packages are keyworded for
> your profile.
>
> # emerge -DNup world
> # revdep-rebuild -p
> --
> [email protected] mailing list

Thanks Harm and thanks to Oliver also.

OK, my system is similar to yours:

[EMAIL PROTECTED] ~ $ ls -l /etc/make.profile
lrwxrwxrwx  1 root root 50 Aug 30 09:50 /etc/make.profile ->
../usr/portage/profiles/default-linux/amd64/2005.1


However, to get the apps running that I wanted to run I've ended up
with a messy set of keywords:

[EMAIL PROTECTED] ~ $ cat /etc/portage/package.keywords
gnome-base/gnome-light amd64
media-video/helixplayer amd64
media-libs/win32codecs amd64
net-irc/xchat-gnome amd64
x11-base/x11-drm amd64

app-admin/eselect-opengl ~amd64
app-admin/eselect ~amd64
sys-apps/sdparm ~amd64
sys-kernel/gentoo-sources ~amd64
x11-themes/fvwm-crystal ~amd64
x11-misc/trayer ~amd64
x11-wm/fvwm ~amd64
x11-misc/habak ~amd64
media-libs/libiec61883 ~amd64
sys-libs/libraw1394 ~amd64
sci-electronics/iverilog ~amd64
media-plugins/mythmusic ~amd64

net-www/mplayerplug-in ~amd64

media-sound/om ~amd64
media-libs/liblo ~amd64
app-emulation/emul-linux-x86-xlibs ~amd64
#media-video/ati-drivers ~amd64
#media-video/ati-drivers-extra ~amd64
x11-base/xorg-x11 ~amd64

app-cdr/k3b ~x86
app-emulation/wine ~x86
media-libs/liblrdf ~x86
media-sound/snd ~x86
media-video/xine-ui ~x86
x11-libs/fltk ~x86

sys-fs/hfsplusutils x86
sys-fs/mac-fdisk ~x86

media-sound/alsa-headers ~amd64
media-plugins/alsa-jack ~amd64
media-libs/alsa-lib ~amd64
media-sound/alsa-oss ~x86
media-sound/alsa-tools ~x86
media-sound/alsa-utils ~amd64
media-sound/alsa-jack ~amd64
media-sound/jack-rack ~x86

x11-libs/fltk ~amd64
[EMAIL PROTECTED] ~ $

A questions though. Just because an app is not tested on AMD64, and
hence not keyworded with amd64 or ~amd64, doesn't mean it has a
problem, does it? It just means it's not tested, right? Or am I
incorrect in that?

Thanks,
Mark

-- 
[email protected] mailing list

Reply via email to