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@xxxxxxxx paul@xxxxxxxxx Key ID: 64A2FF6A
Fortune:
Why aren't fishmongers generous? Their business makes them selfish.
--
fedora-test-list mailing list
fedora-test-list@xxxxxxxxxx
To unsubscribe:
https://www.redhat.com/mailman/listinfo/fedora-test-list