seth vidal wrote : > > Which raises another point : I really hope Seth implements a kind of > > "ExactArchPkgs=kernel kernel-smp glibc" configuration quickly to yum > > "TNG":-) > > So, a good question came up today on discussion about this option. > > How do we add new items to this list. > > let's say in the middle of fc3 an updated packages come out and .i386 > and .i686 packages are made. > > for some misc reason - I'm sure we can all make one up. > > and that package is not listed in ExactArchPackages > > So it migrates up to .i686 > now, what if that is NOT the desired behavior? > > How do we update that config field for that contingency? > > We're still talking about manual intervention, either way. > > I'm just trying to sort out a situation where I'm not fixing one problem > and making another one. Well, if that's not the desired behavior, but doesn't render the system impossible to boot, it's not such a big deal IMHO, since in the vast majority of cases, having the "highest possible compatible arch" will be what is wanted, and in the case of "both i386 and i686 were available... we realized that the i686 specific version brought nothing more, so we only provide i386 from now on", we will also want to update from the older i686 to the newer i386, no? Not to mention the arch to noarch case because it makes more sense for the package (typically the aspell-XX dicts), or the other way around. The only reason the whole ExactArch thingy was brought in the first place was because repositories where the i686 glibc update wasn't included but the i386 one was badly broke clients updating from there (IIRC my server suffered from that, but because you had a mirror problem on at dulug from where I was syncing ;-)). Apart from glibc, I don't think there are other packages that can badly break a system (from the top of my head) if "downgraded" arch-wise, not even the kernel. And from my experience, ExactArch has been a blocker in quite a few situations, like the "filesystem" package which once was noarch and is now arch specific, or multimedia libs initially packaged as i386 _and_ i686 with the i686 build later dropped. Anyway, just my point of view : Having a short simple default for some kind of ExactArchPackages should suit the vast majority of users. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Red Hat Enterprise Linux AS release 3 (Taroon) - Linux kernel 2.6.8-1.521 Load : 0.14 0.20 0.14