x86-64 rawhide update obnoxiousness

Paul Jakma paul at dishone.st
Tue Oct 18 04:10:04 UTC 2005


On Mon, 17 Oct 2005, Michal Jaegermann wrote:

> No, this does not work that way.  If you have A.i386 and A.x86_64 
> installed, and they do have common files, then an attempt to update 
> only one from this pair ends up with conflicts.

Aha, and that's taken care of by rpmlib? Fine so.

> Seth already suggested that yum may have a "pair check" which woud 
> allow either both updates or none.

That would be useful I guess.

>> X.x86-64 is to be upgraded, and depends on a newer version of
>> Y.x86-64, which is pulled in and upgraded.
>

> Here you really have A.i386, A.x86_64, and Common.noarch.  Both As 
> depend on Common.  If you will try to update only, say, A.x86_64 
> this will force an update of Common which will cause "broken 
> dependencies" error for a change unless you are updating A.i386 as 
> well.  So what is the real gain?  Do you plan to loosen up 
> dependencies on Common?  That would open a gate to real horrors.

No no.. read the mail you're replying to ;) - this is for the case of 
file refcounts in the rpm database, nothing to do with package 
splitting.

My suggestion was that this problem would be solved by enforcing 
"must be same version", and as you say above it already does, then 
there's no problem. So refcounts would indeed solve the problem.

The only issue left then would be directories like bin, libexec which 
unfortunately do not have bin64, libexec64 equivalents - a filesystem 
layout issue i guess. (But not a big issue, 99% of time you don't 
really care which arch a binary is, as long as it works. But be nice 
for testing to be able to have both arches of binaries installed).

>  Michal

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
"Turn on, tune up, rock out."
-- Billy Gibbons




More information about the fedora-test-list mailing list