![](https://seccdn.libravatar.org/avatar/f56c176084ab8879a9b598c3046527c2.jpg?s=120&d=mm&r=g)
sorry to bug you lot again but been thinking could this be done by having multiple file lists ie a -0 -1 -2 -3 -4 file list xmls and a cpu capabliaty test added to zypper or call a function to set a flag on starting zypper that decides what one it is to be pulled to use and adding v0 v2 v3 v4 sub directories to x86_64 v0 would hold v0 optimised bins v2 would just be simlinks to v0 code (unless that is compiled for v2 where it could hold v2 compiled bins under the same name) v3 are simlinks to v2 dir unless its optimised for v3 as per above v4 simlinks to v3 code unless v4 versions are there ...etc. but at least simlinking is not going to be a duplicate file needing its own storage space , only where packages are explicitly compiled for a diferent version would that be the case having diferent file lists for zypper should ensure that it only selects the right -v one appropriate to the cpu test so should make this transparent to the user as the lists point to the right location in the repo for each sub architecture resolving the need to have actual apps/libs with differing names and the indepth need to have some built in zapper test on individual different naming packages by no means do i think of this as nothing more than a quick fix , but a simple fix never the less the issue i see using this would be mirrors that could generate full copies of each file when mirroring rather than sim links to them but as each users machine only downloads the single most relivant file list , and only the arcitecture spesific bins from that then bandwith usage is not affected also think it would be a good idea to add a command line option to force-vN (or something )so it could revert to a default v0 basic insall if things get borked up (tempted to let a number be entered by users on force , but this is probablay not a good idea ) where theres a will theres a way have fun