> > > And the obvious candidate for using rpm-python — yum — > has 3 levels of subclassing on an rpm transaction set, all in python, > to provide compatibility with ancient RHEL/CentOS releases. > > yum developers have publicly categorically rejected any/all patches for rpm5 > compatibility as well. > Well, we'll just have to take our chances then and fix whatever needs to be > fixed to reach satisfaction. :o) >
No you can’t just hack out “fixes” because there is no API in rpm-python. The changes in the API (to make rpm-python more “pythonic”) are going to cause instant legacy incompatibility. So there is no possible win, because there are no test cases, just de facto hackery, which will predictably displease both users that expect drop-in Newer! Better! Bestest! functionality, as well as conservative users who expect maintenance support for previously functioning python software. I spent a week considering what to do: I gave up because there is no obvious benefit fixing/changing anything in rpm-python. The issues in rpm-python run far deeper than the rather trivial python2 -> python3 porting. > *shrug* Good luck! > Thx, you make it sound as if we're gonna need it. ;) > Yes you are going to need a whole lot of luck. And you are likely to create Yet Another Fork of rpm-python that is useless outside of a heavily patched single distort context. 73 de Jeff > -- > Regards, > Per Øyvind > _______________________________________________ > OM-Cooker mailing list > [email protected] > http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
_______________________________________________ OM-Cooker mailing list [email protected] http://ml.openmandriva.org/listinfo.cgi/om-cooker-openmandriva.org
