Red Hat Bugzilla – Bug 141561
Allow better control over package selection
Last modified: 2007-11-30 17:07:05 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040510
Description of problem:
Package control, while somewhat flexible, could be a lot more so.
For example, if you could say "Choose packages from channel X, even if
they *are* older", that would be useful. Likewise, if you could say
"Consider versions ending with the string 'jpp' to be newer than other
As to how this could be done, my suggestion is that you arrange some
way that the version comparison (comparePackages) function (in
up2dateUtils) can be overridden. I'm not a Python expert, so I
haven't got any really bright ideas as to how to do it in Python, but
here are some possibilities:
1. Separate the interface and the implementation (like the perl
DBI/DBD classes); then new versions can just inherit the whole object,
and override the compareVersion function (this is probably the best
way to do it, if we can figure out a good way to get up2date to call
the updated object).
2. Another option would be to include a .py file in /etc/alternatives
which contains *only* the compareVersion function, and if people want
to override it, they just change the link in /etc/alternatives
Personally, what I want is to be able to specify versions on the
command line. While this works (using --get) with the default up2date
repo, it doesn't with yum repos (maybe this should be a separate bug).
This would also allow the up2date/JPackage bug (above) to be resolved.
One reason I want to achieve this is to deal with the JPackage stuff
(which is causing problems for me too), and also to make up2date work
with ARPMATS (http://arpmats.sourceforge.net/), and let ARPMATS do the
package name/version selection, but up2date actually find it and
The reproduction fields are inapplicable as this is a request for
enhancement (although the enhancement will resolve at least one other
I've thought of an even better way to fix this one; it's a
"Comparisons" config option. I envisage it working
as specified in the following examples:
# Current operation
# Goes through the repos in priority order, and on the first one that
# has a package-name match, performs the following comparisons (in
# this case, version); we'd also need a way to assign a priority
# to each repo
# If versions don't match, update to newest version
# If versions match, but architectures don't, update to best
Changing the compare would be a start, but it's not
exactly ideal. I'd really rather not undermine the
rpm version compare, since that opens a large can
It's also only a partial solution, since changing
the up2date compare only changes what packages up2date
will try to update. If those packages are older
than whats installed, rpm will not allow that
transaction. So to allow that, the rpm transaction
building bits would need to be tweaked to ignore
If --get doesnt work with yum repos, that is indeed
a seperate bug.
Hmm. Ok, so what *would* be ideal? The problem I'm essentially
running into repeatedly is that neither up2date nor RPM is intelligent
enough to know exactly what packages I want installed. In an ideal
world, I'd always want the newest released version, but this isn't the
case in our current world :).
You're right, though, that up2date would need to give RPM the
equivalent of the --oldpackage command. The question, to my mind, is,
"Of up2date and RPM, which do you trust more to know the desired
package version". Personally, I think that up2date, being at a higher
level, and having more information (ie. configuration from the user
concerning repos) should be in charge of making these decisions, as
RPM knows nothing about repos.
Would it help if I put together a patch to do this, or would you still
not want to incorporate it into the RedHat package?
I'm also aware that others have been asking for similar things over at
the "yum" Bugzilla, but AFAIK, yum doesn't allow updates from the
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.