Re: [gentoo-dev] Re: Cross arch ACCEPT_KEYWORDS in existence ?

[Travis Wayne Tilley]

having x86 in your keywords is an astronomically dumb idea. if you want me to 
explain in detail /why/ it's a VERY dumb idea, I'll try my best to do so...

ebuilds test for keywords the same way they test for use flags, with "arch?" 
in dependency lines and "use arch" inside functions. since your 
ACCEPT_KEYWORDS has x86 in it, these tests to see if you're on an x86 box 
will succeed and the ebuild will configure your install for an x86 box...

one of the more harmless (i assume) examples of this is in the mplayer ebuild. 
with x86 in your keywords, it installs the 32bit win32codecs. your 64bit 
mplayer cant make use of these codecs, and if it somehow manages to try it 
will crash. here is a snippet of the runtime dependency line from the ebuild:

    x86? ( >=media-libs/xvid-0.9.0
           >=media-libs/divx4linux-20030428
           >=media-libs/win32codecs-0.60 )

another example of what could happen is that an ebuild might fetch a 32bit 
binary for a package that would otherwise work and have proper deps on amd64 
when x86 is NOT in your keywords. a large enough number of ebuilds use 'x86?' 
to set the SRC_URI, or location of the file that needs to be downloaded. one 
example i'll just pull out of the air (that may or may not be relevant):

sys-devel/ld.so/ld.so-1.9.11-r3.ebuild:SRC_URI="x86? 
( ftp://ftp.ods.com/pub/linux/${P}.tar.gz )"

another example for that one is mplayerplug-in, which allows for using mplayer 
to play any media format it supports inside mozilla. it works on amd64... 
that is, unless you happen to have x86 in your keywords. with x86 in your 
keywords:

SRC_URI="mirror://sourceforge/${PN}/${P}.tar.gz
	x86? 
( ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.6/${GECKO_SDK} )"

and also:

src_compile() {
	local myconf
	use x86 && myconf="${myconf} --with-gecko-sdk=${WORKDIR}/gecko-sdk"
	econf ${myconf} || die
	emake || die
}

that gecko-sdk is x86-only and will break your build.

what about another example? sure... I've got plenty of them. I mean, the tree 
is seriously FULL of em!! Hey, what about mozilla-firefox-bin? right-o! 
mozilla-firefox-bin is amazing on amd64, since it allows you to use all of 
those 32bit mozilla plugins, such as flash, without screwing up 64bit 
applications that NEED a 64bit mozilla (such as epiphany, nautilus, etc). 
here's the runtime dependency line:

RDEPEND="x86? ( >=sys-libs/lib-compat-1.0-r2 )
	amd64? ( >=app-emulation/emul-linux-x86-baselibs-1.0 )
	x86? ( =x11-libs/gtk+-2.2* )
	amd64? ( >=app-emulation/emul-linux-x86-gtklibs-1.0 )
	virtual/x11
	!net-www/mozilla-firefox"

lets take a look at the first dep, lib-compat. lib-compat contains 
compatibility libs for running libc5 programs and other old apps. these 
things have never existed on amd64.

>>> Unpacking lib-compat-1.3.tar.bz2 to /var/tmp/portage/lib-compat-1.3/work
/usr/sbin/ebuild.sh: line 20: 
cd: /var/tmp/portage/lib-compat-1.3/work/lib-compat-1.3/amd64: No such file 
or directory

OOPS. i'd like to note that the 32bit emul-linux-x86 libraries have all you 
need to run mozilla-firefox-bin on amd64.

hey, here's an example of something just failing to install properly because 
you have x86 in your keywords... xcdroast. here's part of the install 
function:

use x86 && newbin ${DISTDIR}/cdrecord-prodvd-2.01a12-i586-pc-linux-gnu 
cdrecord.prodvd

yup. hey, how about x86 specific device drivers? the glide library isn't 
currently working on amd64... however, if you have 3dfx in USE and x86 in 
your keywords...

        if use x86 || use alpha
        then
            # build with glide3 support? (build the tdfx_dri.o module)
            if use 3dfx
            then
                echo "#define HasGlide3 YES" >> config/cf/host.def
            fi
        fi

...you might just get a broken xfree or xorg-x11.

another prime example is mjpegtools, which enables 32bit assembly if x86 is in 
your keywords. 32bit assembly that a 64bit compiler would see and immediately 
shit itself over.

of course, there are other perfectly harmless examples... like the one in 
linux-headers:

    # This patch fixes an issue involving the use of gcc's -ansi flag and the 
__u64 datatype.
    # It only patches asm-i386, so we only apply it if x86.  Unknown if this 
is needed for other archs.
    # Closes Bug #32246
    if [ -n "`use x86`" ]; then
        epatch ${FILESDIR}/${PN}-strict-ansi-fix.patch
    fi

...but most of them arent that harmless.

'x86?' appears in my snapshot of the portage tree 225 times.
'use x86' appears in my snapshot of the portage tree an additional 135 times.

IF YOU HAVE X86 IN YOUR KEYWORDS DONT EVEN /THINK/ OF REPORTING /ANY/ BUG YOU 
HAVE IN YOUR SYSTEM. It's a waste of quality assurance time that could be 
spent doing something usefull that could actually improve gentoo for amd64.

lesson of the day? when three devs mention over the course of maybe a week 
that adding x86 to ACCEPT_KEYWORDS is a bad idea, they might actually know 
what they're talking about.

as an aside, I agree that we've poorly neglected the stable version of gentoo 
for amd64. up until recently, the tech notes mentioned that if you wanted a 
usefull system at all, you need ~amd64 in your keywords. I dont think I know 
of many people who are /not/ using ACCEPT_KEYWORDS="~amd64"... as a result, 
stable isn't as stable or well tested as testing. I tried getting a number of 
important base packages marked stable in time for the 2004.1 release, but I 
didnt bother with much not included in a normal stage3. I think this has 
really brought to light the fact that we need to seriously concentrate on 
marking packages stable once the 2004.1 release is made. Please keep in mind 
that you could count the number of active Gentoo/AMD64 devs on one hand...


Travis Tilley <lv@g.o>
Gentoo/AMD64 bug stomper extraordinaire
(or, the dude who has to deal with your bug reports and will refuse to touch 
them if he realizes you have x86 in your keywords and are thus wasting his 
time)


On Saturday 10 April 2004 06:57 pm, Sven Köhler wrote:
> > The scenario Meir mentions is basically the lazy-man's way out of
> > updating and maintaining a useful portage for the Gentoo/amd64 community.
>
> well, if i use ~amd64 i get the ebuilds that are to new, if i use amd64
> only, i get ebuilds that are very old. gnome-2.4.2 for example is still
> masked for amd64 - i don't think that there were much changes from
> gnome-2.4.0 (which is marked as stable for amd64) to gnome-2.4.2 that
> prevent it compiling on amd64.
>
> the best way to overcome that dilemma is to use ACCEPT_KEYWORDS="amd64
> x86". Using ACCEPT_KEYWORDS="amd64 ~amd64" would also give me gnome-2.6
> for exmaple, but i don't want that, since the ebuilds are not ready yet,
> and it seems to be a common practice to modify ebuilds without changing
> the "-rX" part of the ebuilds version, and portage doesn't check if a
> ebuild has been modified.

--
gentoo-dev@g.o mailing list