seth vidal wrote : > > What about adding : > > > > - exactarchpkg - a limited set of packages to apply exactarch to if it > > is set, instead of considering exactarch for all packages > > added. Great, thanks! > > I'm still a little hesitant to file bug reports over at Red Hat for the > > packages that are still not noarch although they contain no binaries, > > or even change my own which are in the same case, since I *know* it'll > > cause breakage for the vast majority of users who have exactarch=1 set. > > 1. users can unset exactarch. I'd even be willing to make it a command > option if it would be easier. > > 2. We may be getting to a place where the reason for exactarch is going > away. It might be that distributions are well maintained enough and > people are haphazardly building repository metadata so you will know if > you have all the necessary arches. Well, the last time people were bitten quite hard was when the dulug mirror had sync problems, and the i686 kernel (or glibc?) of an errata didn't pop-up, whereas the i386 did... and I synced from there to offer yum-enabled updates at the time when RH didn't yet. So although repositories may be well maintained, sets of packages double checked before being released, we're never safe regarding a good old rsync/network error combined with automatic metadata generation! ;-) Anyway, my point is that I'd feel so much safer by just having : exactarchpkg=glibc kernel kernel-smp As those are the "nasty" ones that can break a whole system if archs are "downgraded" by mistake (wrt NPTL for example), others just potentially breaking given services without rendering the system unusable or remotely "un-fixable". I think you've heard my point already though ;-) -- Matthias Saou World Trade Center ------------- Edificio Norte 4 Planta System and Network Engineer 08039 Barcelona, Spain Electronic Group Interactive Phone : +34 936 00 23 23
