On Fri, 2003-12-12 at 11:45, Gene C. wrote:
With respect to different architectures ... won't rpm complain on
installing
both (e.g., zlib) even if no conflicts? Every so ofter I forget and try to
update glibc with a simple rpm -Fvh glibc-* and both the i386 and i686
packages in the path ... this does not work (or has not in the past).
The i386 and i686 packages share files that conflict (/lib/libc.so.6 for
example). The i686 and x86_64 packages have different files
(/lib/libc.so.6 vs /lib64/libc.so.6) and so you don't hit the problem.
There are also different rules for handling conflicts of ELF32 vs ELF64
files than just ELF32 vs ELF32 if you have %_transaction_color set
appropriately.
> > 3. I see a lot of packages with /sbin, /usr/sbin, and
/usr/bin files
> > (programs). Depending on which package gets installed last will depend
> > on which architecture's program gets installed. Now, I well believe that
> > this might be "controlable" during the anaconda install process with
some
> > hacks, but how about post install updating?
>
> Not every package is installed in both versions. In particular, you
> rarely want two versions of a program installed.
Granted, some packages with be either/or but not both. However, at least some
of the packages will require both to support both architectures -- glibc for
example. Maybe I do not understand something. Can the x86_64 version of
glibc support its libraries being used by a 32 bit application? The same
question can be stated in the opposite direction -- can a 32 bit library
support being called by a 64 bit application?
No, you need both libraries. But they end up in different paths and so
there's no conflict.
To restate my question in the previous message -- how about using rpm
--relocate oldpath=newpath to resolve some of the conflicts?
Libraries should be built so that they don't have a problem (since the
canonical location for native system libraries on e.g. x86_64 is lib64
instead of lib). For binaries, it really is something you want to
choose and not have two separate sets in two separate paths that may or
may not be in your PATH and ... :-)
Cheers,
Jeremy