Bug 608636

What are you talking about? You can not use 64bit binaries on an 32bit architecture.  Only 32bit binaries on a 64bit hardware platform may work.
Next point is that those links are done by the links scriptlets located
at /var/lib/texmf/link/<arch>-linux/ e.g. on an i586 architecture this
is for texlive-bin you will find the triggerin script

   /var/lib/texmf/link/i586-linux/base

therein you can read in the first few lines:

    #!/bin/sh
    CWD=$PWD
    test "$CWD" = "/" || CWD=${PWD}/
    PATH=${CWD}bin:${CWD}usr/bin:${PATH}
    TARGET=i386-linux
       CPU=$(uname -i|tr '[:upper:]' '[:lower:]')
        OS=$(uname -s|tr '[:upper:]' '[:lower:]')
    set -- ${CWD}usr/bin/../lib/texmf/bin/*
    test "${TARGET}" = "${CPU}-${OS}" -o $# -eq 1 || exit 0
    ln -sf ../lib/texmf/bin/i586-linux/afm2pl ${CWD}usr/bin/afm2pl || true
    [...]

in other words the program uname(1) is used to determine the correct
archtitecture.  Only on ppc64 with ppc(32) user space the hardware
platform is changed from 64bit to 32bit. Please note that the other
way from 32bit hardware platform to 64bit can not work.

If you want to use 32bit binaries on a 64bit hardware platform on x86
you have to do this by hand.  Therefore you have to a fresh install
without using zypper and without using yast.

First of become root and change the use an 32bit program environment
which is done by

      linux32 /bin/bash

with this shell you may do a fresh install.  You should check the
used program environment by calling

      uname -i

if the you see i386 then you can install with the help of rpm all
required packages and the triggerin scripts should do their work.

To be clear: I want to run 32 bit latex on a 64 bit machine. AFAIK this is the only package I know of where the config scripts do not work under these circumstances.

While I appreciate the scripts being pointed out this is hardly a fix.  The package should be more intelligent about detecting what architecture the tex packages are rather than assuming that only 64bit will be installed on a 64bit machine.

"doing it by hand" is not the correct behaviour. The last post pretty much states , "yes it is broken, we know why but we aren't going to fix it [reason not given]".

Furthermore there seems to be a missing dependency - when texlive is changed to 32 bit then latex should also be changed as a dependent package but does not (and it simply does not work with 64 bit latex and 32 bit tex).

These packages should <just work> under these circumstances but do not.

The use

       linux32

to set the correct platform. I'll not go to change the triggerin
scripts.  Otherwise the package texlive-nfs wil not work anymore.

This kludge is not a fix - it should work automatically - the architecture should be determined by the package architecture rather than uname.  Texlive-bin-latex architecture should be dependent on texlive-bin architecture.

The explain why do you want to break texlive-nfs?  For this you can install
all texlive-*-bin packages on on NFS server to export it to several clients
with different hardware platforms all using texlive-nfs.  The triggerin scripts
simply avoid that the execution path on the NFS sever, e.g. x86_64, will be
poison by e.g. ppc.  Without this `kludge' this will not work anymore.  Do you
have a better solution around?

I am unconcerned about texlive-nfs.  I have no interest in texlive-nfs whatsoever. I just feel that when I install 32 bit latex it should work and it doesn't.

Speaking as someone who administers a large mixed platform linux network where everyone uses latex I can put my hand on my heart and say it isn't really -nfs necessary and it is trivial these days to install locally or it would be if the install scripts weren't crippled.

The fix required here should not interfere with texlive-nfs unless texlive-nfs is also broken in the same manner.

This problem appears to be unique amongst suse packages in being so comprehensively broken for little apparent reason.  The proper solution is to fix this bug and then fix any consequences in texlive-nfs.

The kludge suggested is ugly, time consuming and goes against the principles of having a package management system in the first place.  It is easier as a user or administrator to install from the www.tug.org than follow the suggested fix. Especially if you consider the problems maintaining this kludge.

The reason "won't fix this bug because other bugs in other packages rely on it" isn't very good.

BTW I couldn't get the suggested kludge to work - either there is insufficient detail or it just doesn't work, I suspect the meaning of "do this by hand.  Therefore you have to a fresh install without using zypper and without using yast." needs expanding.

Perhaps it means "find and download the rpms, then use rpm to install in the linux32 environment ignoring the dependencies" but it might mean something else.

Having wasted more than enough time I am resorting to original solution...

In other words and if I understand you correct I should ignore all users
of texlive-nfs by dropping it to fix your problem?

Beside this which other packages not related to texlive are comprehensively
broken in which manner?

The current RPMs for texlive 2009 you'll find at

   http://download.opensuse.org/repositories/Publishing/openSUSE_11.0/

This is getting silly -

My point about other suse packages is that they are _not_ broken in this way.

In reply to your question "what about -nfs" my point was I don't care what happens to this - my bug report relates to the broken latex package and you shouldn't refuse to fix this bug just because the config scripts in another package are dodgy, perhaps you should fix both?

I presume that since this has degenerated in stupid trolling instead of bug fixing the solution is going to be bugger all is done. 

It is clearly a bug - there has been no suggestion that it isn't a bug. The kludge suggested is not a fix.  I can't see a good reason not to fix the package(s).

I've tried to work around the problem including to support texlive-nfs
as this package is used by more than one user.

As the rpm on 11.0 can not handle %triggerprein this could be a problem,
nevertheless see
http://download.opensuse.org/repositories/Publishing/openSUSE_11.0/

I wasn't entirely sure what was suggested above but I tried:

The texlive-bin-latex package from:

http://download.opensuse.org/repositories/Publishing/openSUSE_11.0/i586/texlive-bin-latex-2009-56.1.i586.rpm

I remove the old texlive-bin-latex and install the new one then reinstalled texlive-latex.

Result no change, script / links still missing and latex still doesn't work.

I also have a related problem with xdvi:

xdvi
/usr/bin/xdvi: line 31: kpsewhich: command not found
/usr/bin/xdvi: line 59: exec: xdvi-xaw3d.bin: not found

Presumably as a result of the scripts not running as required.

I'm fixing with symbolic links.

Should be fixed know for factory ... know the links are part
of the architecture depend rpm's.

*** Bug 660370 has been marked as a duplicate of this bug. ***

This is an autogenerated message for OBS integration:
This bug (608636) was mentioned in
https://build.opensuse.org/request/show/53340 Factory / texlive-bin