On Thu, 2012-04-26 at 16:24 +0200, Phil Knirsch wrote: > On 04/18/2012 04:29 PM, James Antill wrote: > > On Wed, 2012-04-18 at 15:37 +0200, Phil Knirsch wrote: > >> Yea, it's kinda butt ugly, but the problem is that rpm doesn't have an > >> API for it, even less so for the python part that would be required. > > > > Yeh, just seems that one of the bester cases here would be having an > > "rpm API" that says "give me the current AT_PLATFORM and/or AT_*". > > Even if we don't move/merge "all" of the arch detection code into rpm, > > at least having those would be good. > > > > The latest patch i've attached for now basically do the same as rpm > does. Once we have the rpm API in place we can switch over to that > easily. Basically replaced the evil /bin/true ENV parsing hack with a > proper general purpose /proc/self/auxv parser in python directly, so > basically the cleanest way we can do this for now. And i've done it just > like in rpm, so any other arch can access and use the > aux_vector["platform"] and aux_vector["hwcap"] information.
Ok, did some minor cleanups and pushed (feel free to double make sure I didn't break anything). > Could we get a f-17 version with that change out soon too please? rpm > already contains the necessary changes, and we'd really love to get this > test for F-17 beta on PPC which we're aiming for next Wednesday. Sure. _______________________________________________ Yum-devel mailing list [email protected] http://lists.baseurl.org/mailman/listinfo/yum-devel
