> . > > Of course the build host cannot know, or infer where its > product will later be installed. > > Probably the best one could do is query rpm version at > runtime, and then if == 4.1.x, set a flag, and if it faults > out, catch and return a error message in the python code > suggesting this as a possible issue. > ok I know another answer. an easier one - but it might not be easier for the people who have to implement it. I'd like some feedback on this. Systems that can and are using rpm 4.0.4 and/or the rpm404 bindings should use yum < 1.0. Those people using rpm 4.2 or higher should use yum > 1.0 My goals were/are mostly to follow the red hat releases. 7.1, 7.2, 7.3 and 8.0 are all served by yum <1.0 (0.9.4 in this case) TNV (8.1 or something I'd guess) will use yum > 1.0. Keeping compatibility for all versions of rpm forever will make the code a mess, but not keeping some compatibility makes it harder for users. The things I intend to put into yum include comps.xml support and an array of other things that will REQUIRE python2.x and a lot of modules built for python2.x I've been following anaconda fairly loosely - in rhl 8.0 anaconda did an: import rpm404 as rpm. in the current beta anaconda has been ported to work with rpm 4.2, so I did the same. What do people think about that? Is that a horrible idea? Or just lazy? Maybe this is the time for the break b/c of how much of a departure rpm is at this point. The new requirements for later versions of yum would be: rpm-python >= 4.2 python >= 2.X is that not fun for a lot of people? -sv
