> > > > 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 ...