[Yum] kernel-source arch

[seth vidal]

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

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