> >
> > It is a step in the way forward.  It definatly is much better than not having
> > the i386 rpm's in the x86_64.
>
> I agree. I'm just afraid the colleagues from CERN won't like it because
> apt can't handle this yet. But then, rumours say that it's being worked
> on.

Colleagues at CERN ;-) also added these for Scientific Linux CERN 3.0.3
(release candidate just out today):

The initial system installation will handle above without any problem
(of course ;-)): it is true that currently apt cannot do multi-arch
updates but:

   - x86_64/ia64 are not our production environments right now (and
     still for some time to come)

   - apt can be easily extended via LUA scripts (so if there's an
     upgrade on 32 bit packages on 64bit system we can hook-up a
     workaround script using rpm directly - for example)

   - we can provide one-time off scripts to do 32bit upgrades/installs
     using rpm ...

(yes ... most of above is not too 'nice' .. but better than nothing)

   - indeed apt people (;-)) are working on multi-arch (.. not very
     fast though ...)

>
> The nasty part is that if you have the x86_64 package installed, and then
> install and remove the i386 package, all files shared between them are gone.
>

.. yep .. (I've also seen inconsistent overwrites of binaries depending
on the order of 32/64 bit install/remove/update operations ...)

> And yum refuses to install kernel-unsupported.ia32e on my shiny
> new EM64T test system because it insists that x86_64 is the one and only
> architecture I should install for.

(isn't it because your yum.conf contains exactarch=1 ?)

> But I expect all this to work eventually. And since I looked into RHEL4
> beta 1, and they're doing it just the same way there, it's probably the
> way to go, ugly or not.

It looks like ... personally I would prefer much more SuSE/Debian
packaging: 32bit packages are recognized by name alike:
XXXX-32bit-VVV.RRR
(this needs of course extra package building ... versus copying from
i386 build)

.. but I guess we have to live with Red Hat way ...

Jarek ([log in to unmask])

--
general signature fault ...