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 versions". 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 download it. How reproducible: Always Additional info: The reproduction fields are inapplicable as this is a request for enhancement (although the enhancement will resolve at least one other bug).
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 Comparisons=version ----------------- # 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 Comparisons=repo-priority,version ----------------- # If versions don't match, update to newest version # If versions match, but architectures don't, update to best # architecture Comparisons=version,arch ------------------ # Combo Comparisons=repo-priority,version,arch HTH,
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 of worms. 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 versions. 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 RHEL3 repo. Thanks,
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: http://www.redhat.com/security/updates/errata/ 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.