James Antill wrote: > On Fri, 2012-03-30 at 19:15 +0200, Andy wrote: >> Hi, >> I'm running Scientific Linux 6.2 x86_64 (Redhat 6.2 clone) and I also manage >> a >> repo for it, which has both i686 and x86_64 packages in it, that aren't >> always >> exactly at the same version. > > Yeh, don't do that.
Surely the fact that I haven't done separate repos for i686 an x86_64 is not the issue here, as I would imagine the same problem would happen with separate repos the moment I also enable the i686 repo on the x86_64 box (for example for dependecies of skype and adobe reader or similar binary-only packages). I mean having an i686 repo enabled on a x86_64 box is a perfectly legitimate situation, and in such a situation yum shouldn't try to update x86_64 packages with newer i686 versions. I would consider this behaviour a bug as I cannot think of any legimitate situation where anyone would want a x86_64 package replaced by a newer i686 package. > Traditionally we had that option, and implemented that behaviour > because of repos. releasing glibc.i386 before the corresponding > glibc.i586 and everything dying if the user moved to the "new > version" ... so it was about staying on the "exact" arch within the same > arch family. Thanks for the historic background info. In that case I imagine that fixing yum to also avoid replacing x86_64 packages with iX86 packages shouldn't be hard to implement.(unfortunately I know nothing about python... :( ) In fact I would imagine the code should be fixed to be generic, when doing an update yum should never switch package arch, i.e. it should only consider newer version packages that are the same arch as the currently installed ones for each individual package. > Fix the repo. ... really. If you can't do that for some reason, then > I'd probably recommend using excludes. Yes 'excludes' would solve this issue, but it's a very messy workaround. Like I said above, I don't see how fixing the repo solves this (give that I would still need the x86 repo enabled for specific packages on some boxes). _______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
