x86-64 rawhide update obnoxiousness

[Paul Jakma]

On Mon, 17 Oct 2005, Michal Jaegermann wrote:

> That is exactly what to me looks like something sane in the whole 
> context.  Similar to how 'unlink' works.  Files are removed only 
> when the last reference is gone.  It appears that something of that 
> sort already happens for directories but maybe I am misinterpreting 
> some observations.

It'd solve the "remove" problem.

> Obviously you are still left with cases, like mentioned /bin/tcsh, 
> where you have really different files but with the same name and 
> you install both "owner" packages.  That sounds like a bug although 
> it appears that one can have some "messy rules".  Say, in 
> x86_64/i386 situation x86_64 is "preferred" and a file from that 
> architecture cannot be replaced with another variant.  So even if 
> you had tcsh.x86_64 and tcsh.i386 packages installed and you 
> managed somehow to remove the first one then you are left with 
> x86_64 executables in /bin/tcsh.

Well it's two seperate bugs really:

1. It appears rpmlib's "swallowing" process does not check the files
    are actually same, as you had initially thought. In lieu of a
    better solution than "swallowing" multi-arch file conflicts, it
    should check the MD5/SHA1 of the file being considered for
    installation against the file on disk - as you had thought it did
    initially.

2. A packaging / fs layout bug: We really should put x86-64 binaries
    in a seperate directory, bin64, or bin/64. This is how both
    Solaris 10 and IRIX do things and it allows multi-arches to be
    installed without clobbering the binaries. (You can play tricks
    with bind mounts to make bin/$ISA appear as bin..).

    /usr/libexec has the same "undefined arch, hence target
    installation directory for multiple arches" problem.

>> But that doesnt allow higher-level package management systems to 
>> spot such dependencies though.
>
> How that would be really different?

Because the refcount would be a dependency, but that dependency isn't 
expressed anywhere, hence it's invisible to yum. The problem is 
similar to the dependency chain you noted in a previous mail, except 
your package management system can't see it and can't do anything 
about it.

X.i386   -> Y.i386 (X depends on Y)
A.x86-64 -> Y.x86-64

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

However, there is no dependency information to tell you that files of 
Y.x86-64 are shared with Y.i386 (unless you do something like 'rpm 
-qf' for each file to be removed, but that's cumbersome), so you 
could end up with documentation from a newer Y.x86-64 which is 
confusing if you want to use binaries from Y.i386.

Of course, you could just simply make a rule that packages of the 
same name *must* always be upgraded in lock-step. (And that really 
should then be enforced by rpmlib).

>   Michal

regards,
-- 
Paul Jakma	paul at clubi.ie	paul at jakma.org	Key ID: 64A2FF6A
Fortune:
Why aren't fishmongers generous? Their business makes them selfish.