[Yum] kernel-source arch

seth vidal skvidal at phy.duke.edu
Wed Jun 30 06:28:49 UTC 2004

On Tue, 2004-06-15 at 15:49 +0200, Matthias Saou wrote:
> seth vidal wrote :
> > > How about something like "exactarch=glibc kernel kernel-smp" being
> > > recognized? There are actually few packages for which the wrong arch
> > > can lead to disaster, and there are many more for which it's no big
> > > deal(like gzip, or 3rd party packages going from i386 to i586 because
> > > of enabled mmx stuff etc.). Just a thought.
> > 
> > That's probably not a bad idea but it has two problems:
> > 
> > 1. it makes the updates processing mind numbingly difficult to follow
> In practise, it's more difficult than just "do as if we had exactarch=1 for
> the packages listed, do as if we had exactarch=0 for all others?" when
> going through the dependency resolving?
> > 2. it's a change that can't be made in the current stable branch b/c it
> > will change too many people's config files in midstream.
> Why would this be so? If 0/1 still works (ok... there will be a non-working
> corner case, if someone wants exactarch for only a single package called "0"
> or "1" ;-)), and if the implicit default stays the same, then all existing
> installations shouldn't see any difference unless the config is changed, no?

I was working on this when I thought of an odd case  which makes
exactarch=packagename, packagename, packagename 

x86_64 or ppc64 or sparc64

In that case you don't want any package to be 'update' with an arch
change or you could have

foo-1.1-1.i386 installed
foo-1.2-1.x86_64 available
foo-1.2-1.i386 available

running on an x86_64

in that situation yum would look for the bestarch for the platform and
clearly x86_64 is better than i386, so then foo-1.2-1.x86_64 would
update foo-1.1-1.i386
That might be technically, correct, but there's a good chance that is
NOT what the user wanted.

now, in the case of i386 alone it's not a big deal you only have a
handful of packages you worry about the arch changing, but in the case
of the 64bit arches this becomes a problem - there are hundreds of
packages that have more than one arch, and any one of them could screw
up your system.

Thoughts on other options?

More information about the Yum mailing list