On Wed, Jun 30, 2004 at 02:28:49AM -0400, seth vidal wrote: > 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? Perhaps alowing always to switching from and to noarch? While discussing whether i686 is better or worse than x86_64, noarch is simply not comparable. If two packages with the same NEVR exist, but are noarch and no-noarch ;), then it is definitely a bug in the repo and yum should return "Error: hunt and kill the repo maintainer" ;) -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.dulug.duke.edu/pipermail/yum/attachments/20040701/82435cbe/attachment.bin
