On Jan 27, 2011, at 2:47 PM, Per Øyvind Karlsen wrote: > d'oh, sent with wrong email address.. > > 2011/1/27 Per Øyvind Karlsen <peroyv...@mandriva.org>: >> 2011/1/27 Jeff Johnson <n3...@mac.com>: >>> There's a deep political rift aka labelCompare() involving missing values >>> that needs to be sorted through here. >>> >>> The same political rift affects your "fix" with missing values (my comment >>> was something arch like "You changed too many lines of code and there needs >>> to be test cases first." I can find the explicit message if you don't >>> recall) >> I ended up reverting the change in lack of test cases though.. ;) >>> >>> The political rift is largely that the python script kiddies and >>> labelCompare() >>> are doing things differently than what RPM is doing. The issue is solely >>> that there are different conventions for missing values that prevent >>> otherwise identical code from being collapsed through re-factoring. >>> >>> But its not my job to teach script kiddies how to program or otherwise >>> relieve them of their ignorance. Lord knows I've tried to do so for years >>> and years and years. *shrug*. >>> >>> Meanwhile I no longer give a rat's ass crap about legacy. But you might want >>> to coordinate the change with Ander's and smart before we have Yet Another >>> Food Fight >>> in the rpm-python cafeteria. >> There's the obvious issue of legacy/API compatibilty, but how to deal with it >> is hard to fully decide in the python bindings though, and practicality of >> these >> functions and benefit of getting same behaviour as RPM are hard to argue with >> (regardless of smart, especially if wanting to support any different version >> comparision scheme than using the order of EVRD).
There's all sorts of issues, and unless you know the hysteria, you will NOT see them in the code. With a fork and FUD everywhere, rpm-python has been essentially dead in the water for 5+ years. I do not see that changing, and is in fact why JavaScript is the chosen binding language @rpm5.org. Too bad for Python script kiddies, who will have to make their own way forward with whatever version of RPM they choose. There is explicit and serious negative interest -- not from me -- in using @rpm5.org. Have fun! Not my problem mon. >> The python bindings really should get some attention. first of all >> just cleaning up >> and fixing any existing issues. Moving past that, doing new >> development on features >> and functionality, legacy compatibility for bindings and/or any tools >> (such as smart) >> using them will both get painful if wanting to ensure compatibility >> with ie. rpm.org >> as well.. From an engineering POV yes, the rpm-python bindings @rpm5.org need to be overhauled. I've said this many many times over the last few years and there is NO detectable interest. So I do JavaScript (with GPSEE -> rpmlib) instead. Life's too short. >> >> So yeah, implementing function in python bindings are trivial, the benefits >> quite obvious, fitting it into smart OTOH will require more thinking, >> discussion and >> coordination.. For smart in Mandriva, I really want to make sure of >> consistent >> behaviour with urpmi and rpm itself, which makes it important for me at least >> to be able to switch back and forth between the two. Go for it! I did in fact write rpm-python bindings, am fully cpabale of assisting with the engineering work. But I will NOT be smeared by FUD politics any further. I wish my privacy. 73 de Jeff______________________________________________________________________ RPM Package Manager http://rpm5.org Developer Communication List rpm-devel@rpm5.org
