[Yum] error report -- latest tarball yum-20030203.tar.gz

seth vidal skvidal at phy.duke.edu
Tue Feb 4 03:48:29 UTC 2003

> .
> 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?


More information about the Yum mailing list