[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
  Web www.spinics.net

Re: how to not let multiple arch rpm coexist

On Thu, 2012-03-29 at 13:48 -0700, Rich Rauenzahn wrote:
> [Not sure if this is a yum question, or an rpm question.. but since
> yum is driven by rpm metadata, I'll start here?]
> We've noticed sometimes if there is both a 32bit and a 64bit version
> of a package in a repository yum will only install one of them.  But
> sometimes it will prompt to install both.

 This should be controlled by the multilib_policy configuration (if it's
all, then "yum install foo" will install both, if "best" it'll just
install foo.x86_64).
 You can also explicitly list the arches you want. If this isn't what
you mean, you need to give more information about what is happening.

> Allowing only one is appropriate when the binary goes into /usr/bin,
> and both packages can coexist just fine if they are libraries that go
> into .../lib or .../lib64

 There are currently no heuristics like this, one problem with trying
this would be that yum would need to download the filelists metadata.

> We're building a package (i386 and x86_64) that installs a binary into
> /usr/bin, yet yum seems to think both can be installed, similar to
> libraries.  We don't want this...
> Is this controlled through some rpm metadata specified in the spec
> file?  I've had no success with google or rpm documentation.

 The usual thing to do is just not put the .i?86 version in the .x86_64
repo. ... in theory you could add a conflict on "the opposite of _isa"
but you'd have to do that manually, and it won't stop yum trying to
install both arches (if multilib_policy=all) ... it'll just make yum
refuse to depsolve that.

 If you need both to be available, and have multilib_policy=all you
could do something like the SuSE/zypp multilib. support where you have
foo.x86_64 and foo-32bit.i?86 (not forgetting to add conflicts).

Rpm-list mailing list

[Linux Kernel]     [Red Hat Install]     [PAM]     [Red Hat Watch]     [Red Hat Development]     [Red Hat]     [Gimp]     [Yosemite News]     [IETF Discussion]