extras-buildsys/utils/pushscript/yum Errors.py, NONE, 1.1 __init__.py, NONE, 1.1 comps.py, NONE, 1.1 config.py, NONE, 1.1 constants.py, NONE, 1.1 depsolve.py, NONE, 1.1 failover.py, NONE, 1.1 logger.py, NONE, 1.1 mdcache.py, NONE, 1.1 mdparser.py, NONE, 1.1 misc.py, NONE, 1.1 packages.py, NONE, 1.1 parser.py, NONE, 1.1 pgpmsg.py, NONE, 1.1 plugins.py, NONE, 1.1 repos.py, NONE, 1.1 sqlitecache.py, NONE, 1.1 sqlitesack.py, NONE, 1.1 transactioninfo.py, NONE, 1.1 update_md.py, NONE, 1.1

[Michael Schwendt]

On Sun, 15 Oct 2006 09:42:22 -0400, seth vidal wrote:

> On Sun, 2006-10-15 at 05:30 -0700, Michael Schwendt wrote:
> > Author: mschwendt
> > 
> > Update of /cvs/fedora/extras-buildsys/utils/pushscript/yum
> > In directory cvs-int.fedora.redhat.com:/tmp/cvs-serv30805/yum
> > 
> > Added Files:
> > 	Errors.py __init__.py comps.py config.py constants.py 
> > 	depsolve.py failover.py logger.py mdcache.py mdparser.py 
> > 	misc.py packages.py parser.py pgpmsg.py plugins.py repos.py 
> > 	sqlitecache.py sqlitesack.py transactioninfo.py update_md.py 
> > Log Message:
> > Add the patched yum 2.6.1 here, so we remove the dependency on the
> > system-installed one
> 
> Michael,
>  This is insane for a couple of reasons:
> 
> 1. yum 2.6.1 does not play well with the python on rhel4 - that's what's
> running on extras64
> 2. you've checked in ALL the code into fedora cvs for this? Cmon -
> that's just wrong.
> 
> 
> Revert this and explain what you were trying to fix, maybe I can help.

The same code has been in production use for a very long time, because it
is needed by Extras repoclosure. It's far from insane, because so far it
gets the job done, which should be in our best interest.

The system's installed yum is 2.6.0 and does not include the
"checkForObsolete" feature, which avoids all the false positives in the
reports.

The multilib support in the push script, which is in production use for
several weeks by now (taking care of copying Wine including dependencies),
also needs a stable yum API. I've seen API breakage in yum >= 2.9 (as you
known from at least one bug report) and want to avoid that any future
upgrade of the system's yum causes trouble.

Yum is not part of RHEL4. CentOS 4.4, on the other hand, contains only yum
2.4.3, so I have no idea where this 2.6.0 version (and several other rpms,
like repoview and createrepo, come from) and whether it might be upgraded
suddenly.

The one true solution to this would be a guarantee of API stability
including the checkForObsolete code and a well-defined and announced
window before a planned upgrade of yum.