yum pulling in 386 packages

David Woodhouse dwmw2 at infradead.org
Mon Sep 24 22:09:22 UTC 2007

On Mon, 2007-09-24 at 09:59 -0600, Richi Plana wrote:
> On Mon, 2007-09-24 at 16:20 +0100, David Woodhouse wrote:
> > On Mon, 2007-09-24 at 09:54 -0500, Chris Adams wrote:
> > > Why keep the i386 versions in the repo?  It would be better to write
> > > down the rules that are used to pull i386 packages into the x86_64
> > > repo and then make a yum plugin that can point to the i386 repo and
> > > follow the rules (when enabled).
> > 
> > There's a lot of sense in this. One of the options being discussed is to
> > ship _nothing_ of the secondary arch (or almost nothing) in the primary
> > repository, and allow yum to be pointed at the basic i386 repo.
> One problem with this is that many arch-specific packages contain 1)
> arch-neutral resources in them (like documentation, data files and
> arch-neutral scripts) and 2) some binaries in /usr/bin that collide with
> each other. Ideally, a solution like that would allow installing of
> packages from any arbitrary architecture (say, ppc and i386) without
> there every being any collisions. Unfortunately, neither the
> alternatives system nor FHS supports multi-arch installs.

That's kind of an orthogonal point -- yes, it's an issue with our
existing multilib setup, but it's not directly related to the question
at hand, of which packages should be installed by default for the
secondary arch and how they should get there. And it's made neither
better nor worse by what Chris proposed.

It's also something which is partially addressed by something on the
multilib tracker bug. Have you looked at that?

> Even the current i386-x86_64 installs aren't perfect. The library
> separation and linking works alright, but the executable programs
> in /usr/bin don't (e.g. /usr/bin/soundstretch installed in both
> soundtouch.x86_64 and soundtouch.i386 is x86_64 only).

This is bug #235757 (ignore the temporary bit for F7 to prefer 32-bit).

> Does anyone see /usr/(bin|lib).(i386|i686|x86_64|ppc|ppc64) in the
> future? :-)

No. :)


More information about the fedora-devel-list mailing list