Bug 141561

Summary:	Allow better control over package selection
Product:	Red Hat Enterprise Linux 3	Reporter:	Tim Nelson <tim.nelson>
Component:	up2date	Assignee:	Bret McMillan <bretm>
Status:	CLOSED WONTFIX	QA Contact:	Fanny Augustin <fmoquete>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	3.0	Keywords:	FutureFeature
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-10-19 19:12:26 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Tim Nelson 2004-12-02 02:40:24 UTC

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

Comment 1 Tim Nelson 2004-12-02 03:53:32 UTC

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,

Comment 2 Adrian Likins 2004-12-02 22:15:05 UTC

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.

Comment 3 Tim Nelson 2004-12-03 03:20:13 UTC

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,

Comment 4 RHEL Program Management 2007-10-19 19:12:26 UTC

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.