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