From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040612 Firefox/0.8 Description of problem: ===****=== These python's will install together, but in a certain order. python22 first, then python installs correctly. python, then python22 will remove python: ftp://ftp.python.org/pub/pyvault/redhat/9/i386/html/index_testing.html If the python revision is 2.3.4-108 instead of 2.3.4-107, rsync must have nuked it. Try a mirror: http://mirrors.combose.com/python/pub/pyvault/redhat/9/i386/html/index_testing.html ===****=== These python's have a big daddy: python-2.3.4, who will nuke the other two upon installation (when the other two are already installed). You can just download 2.3.4-108.0.rh9.pyv release of python. It's a SLOW 29KBps DSL uplink. http://symbiont.shacknet.nu/redhat/9/i386/html/index_testing.html ===****=== Thanks for your much needed eyeballs. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Using release 107: 1. Install python22. 2. Install python. 3. Test OK. 4. Remove python, python22. 5. Install python. 6. Install python22. 7. Test FAILS: python is removed. (Obsoletes: python = 2.2.2 in python22; Provides: python, in python-2.3.4) Using release 108: 1. Install python22, python15. 2. Install python. 3. Test FAILS: rpm tries to remove python22, python15. Actual Results: can't get python, python15, python22 to install in any order I want. Expected Results: can get python, python15, python22 to install in any order I want. Intended goals: http://distro2.conectiva.com.br/pipermail/apt-rpm/2004-August/002517.html Additional info:
The core problem here, as I understand it, is that recent versions of rpm (4.2.1 and newer I believe), have the bug, err, feature that an included Provides: foo implies Obsoletes: foo
Alrighty, I've done some more research on this issue with the assistance of Jeff and Paul. The blanket statement that "Provides: foo implies Obsoletes: foo" is actually not true. The problem really is that every package has an implicit "Obsoletes: %{name} < E:V-R" based on the usual tags we all know and love. This is supposed to happen so that -U can work on moving from python-2.2.2 ==> python-2.3.4. The renaming of python-2.2.2 ==> python22-2.2.2 and placing a "Provides: python = %{version}" in python22 will mark it for destruction when running -U with python-2.3.4 because of this. So, moving forward--correct me if I am wrong, please--I have the following options: 1. Drop the policy of a single python22 and ensure that both packages are installed while checking the dependencies on "python = 2.2.2" don't get nuked. 2. Rename python-2.3.4 to python23-2.3.4 and "Provides: python = %{version}" in all. 3. Figure out how to negate the implicit Package-level Obsoletes so that it doesn't nuke other compat packages. Anyway, check out my sandbox here on some quick experimental specs that Paul provided (no pun intended): http://symbiont.mn.sabren.com/sandbox/. Let me know what Option you think is possible and the best for my situation. Appreciate it, jeff
2 approaches can be made: 1. modify rpm to not destroy Virtual Provides via Obsoletes. Obsoletes should only nuke *real* packages/rpms named "foo", not *any* package/rpm that contains 'Provides: foo' I don't know much about rpm's internals, so I don't know if a distinction between a "real" package/rpm and a "virtual/Provides" one can be made. 2. Workaround the implicit 'Obsoletes %{name} < E:V-R" by making sure your "%%release" portion of 'Provides: foo-%%version-%%release' is high enough not be affected by the implicit Obsoletes
> 2. Workaround the implicit 'Obsoletes %{name} < E:V-R" by making > sure your "%%release" portion of 'Provides: > foo-%%version-%%release' is high enough not be affected by the > implicit Obsoletes I cannot implement this because there are existing packages that: Requires: foo >= 2.2 Requires: foo < 2.3 So, for foo22 to satisfy this logically (it already satisfies physically via the correct files, etc.), then it needs to: Provides: foo = 2.2.2 However, foo implicitly Provides foo = 2.3.4 and Obsoletes anything (including virtual provides) less than its own version. So, my only hope is to implement my Option #2 from above: Do not name any package name "foo" and stick with "foo15", "foo22", and "foo23". If all agree to this point, I will proceed in this fashion.
For interested parties, I've implemented Option #2 and I've provided a SPEC that demonstrates the Implicit Uber-Obsoletes that cleans out both real and virtual providers. This is listed as provider-faulty23.spec (from my perspective, although, maybe this is really the desired behavior.) Since Option #2 works, I'm going to move forward on the implementation. Although aesthetically the genealogical layout is not as appeasing, it's what will work on most existing distros at this time. Download the specs here: http://symbiont.mn.sabren.com/sandbox/rpm/ Run "rpmbuild -bb *spec". Download the "test.sh" script. As root Run ". ./test.sh" in the directory where the RPMS were generated. This test fixture will allow one to observe the behavior of Obsoletes in an easier, controlled environment.
See also commentary in bug #111071 regarding the "it's a feature not a bug" implicit Obsoletes. (-:
I did not say "feature", I said that the behavior is indeed intended: This is the implemented and desired behavior, not gonna change.
Semantics. In my mind "feature" is interchangable with "implemented and desired behavior", even though I would argue whether this behavior is necessarily desirable. All I know is that it made things hard for packagers who depended upon previous behavior, and I see no gain achieved by it (though I'm sure there is, or you wouldn't have done it... right?).
What's the status of this bug? It makes concurrent installs of packages providing a similar entity impossible. This is not restruicted to multiple python packages, but also to multiple compilers etc. If Provides: is defined on a rpm specification level to have this behaviour and this will not change, then we need another keyword for example Provides(noupdate): python = 2.4.0 [...] Provides(noupdate): python-devel = 2.4.0 in python24, so that Requires: python-devel >= 2.4.0 can be used (and thus no rewrites of specfiles for python24-devel and the like). The larger the community around Fedora becomes the more forward/backward compatibility packages will be required.
Hm, this also heavily breaks the python-abi/python(abi) virtual provides method. I.e. it is not possible to have two pythons installed no matter what the package name, when both have provides for python-abi and/or python(abi). The python with the higher python(abi) will remove the other one. Or in order to have two pythons installed one of them may not have a python(abi) provides which breaks the purpose of python(abi). So the current situation breaks the use of python(abi). AFAICT there is no constructive use of this behaviour of rpm (implicitly obsoleting virtual provides), while it certainly obstructs creative use of multiple packages per package version.
This also breaks when compat-db provides libdb-X.so (and it provides dbY = X) on a platform and only it is installed to satisfy core pam/perl requirements. Then, when another package comes in and needs libdb-Y.so provided by package dbY, dbY will try to nuke compat-db during Uvh because it has provided dbY at an earlier version point. Extremely annoying. I'm not sure why the implicit Obsoletes is needed ... it truly has become a burden. I have to manually retool mach builds for legacy backports of db4. I know that many don't really care about this, but I can see problems in the future trying to provide multi-set packages, whatever they might be, and dealing with subsequent upgrades.
The as intended behavior is going to remain exactly as is in rpm.