09.05.2014 18:53, Peter Maydell пишет: > On 8 May 2014 09:30, Michael Tokarev <m...@tls.msk.ru> wrote: >> Here's a pull request for glib pre-2.31 compatibility layer and libcacard >> cleanups on top of it. It has been submitted for review previously: >> >> v1: http://thread.gmane.org/gmane.comp.emulators.qemu/269432 >> v2: http://thread.gmane.org/gmane.comp.emulators.qemu/270259 >> >> Previous attempt of adding glib compat layer by Stefan Hajnoczi: >> http://thread.gmane.org/gmane.comp.emulators.qemu/253830 >> >> Changes since v2 submission: >> >> - dropped 3 trivial changes which were applied meantime >> - fixed coding style (identation/spacing) in first patch >> alevy: I hope these tiny spacing changes are okay for >> you to keep your reviewed-by ;) >> >> Please consider applying. Since this touches several areas of >> qemu, there's no clear maintainer so I'm not really sure which >> maintainer tree should pick this up. And it isn't very suitable >> for -trival either :) > > I'm still a bit dubious about the approach this patchset > takes to glib back-compatibility (ie using #defines etc > to fake up the new glib API on older glib versions, rather > than defining wrappers), and it sounded from the conversation > on IRC today as if Stefan was also not completely convinced. > So I don't think there's enough consensus to apply this > yet, and I'd rather we had more discussion/review first.
This whole thing is almost moot really. It is an old glib API, and no one cares about it anymore except redhat, because it is the only distribution nowadays which is relevant and ships that old glib. We're discussing adding compat layer in qemu for thing which is almost irrelevant for everyone else who moved on to the new API and don't care about old crap. I tried to make old redhat glib API to be almost compatible with current glib, _just_ to not introduce additional version requiriment. For an API which is frozen and wont change anymore, and which is almost unused in whole qemu too. The layer which I provided actually works and is actually tested on several different platforms. For me, I don't care a damn about this old crap. New glib API works on all relevant versions of Debian for example, so I can just clean up crap in libcacard using new API directly - ofcourse it wont be upstreamable due to that old glib api which is still relevant, but at least we'll have a proper libcacard in Debian. I just wanted to do the dirty work for everyone's benefit without adding new complexity. If that's not needed, no worries from me. The 2 remaining libcacard patches are small and trivial enough to keep in debian tree. Thanks, /mjt
