AMD64 Linux documentation

[Gene C.]

On Friday 12 December 2003 11:14, Michael K. Johnson wrote:
> On Fri, Dec 12, 2003 at 11:08:08AM -0500, Gene C. wrote:
> > 2.  I understand that the /etc and /usr/share files do not likely matter
> > since they will be most likely identical.  However, won't rpm still
> > complain since you already have the package installed even if for a
> > different architecture (ix86 vice x86_64) ... and if not about the
> > package then about the duplicate files?  Somehow, using --force does not
> > seem to be a good solution since it overrides and lot of safety checking.
>
> Since the very beginning of RPM, it has been OK to share *identical*
> files between packages.  They are refcounted and only removed when the
> last package referencing them is removed.

I had not realized that really identical files were OK to be shared ... 
interesting and useful feature.

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

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

To restate my question in the previous message -- how about using rpm 
--relocate oldpath=newpath to resolve some of the conflicts?
-- 
Gene