Bug 130352 - Difficult time getting multi-python pkgset working.
Summary: Difficult time getting multi-python pkgset working.
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-19 14:54 UTC by Jeff Pitman
Modified: 2007-11-30 22:10 UTC (History)
8 users (show)

Clone Of:
Last Closed: 2006-04-25 04:20:36 UTC

Attachments (Terms of Use)

Description Jeff Pitman 2004-08-19 14:54:48 UTC
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:


If the python revision is 2.3.4-108 instead of 2.3.4-107, rsync must
have nuked it.  Try a mirror:



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.


Thanks for your much needed eyeballs.

Version-Release number of selected component (if applicable):

How reproducible:

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:

Additional info:

Comment 1 Rex Dieter 2004-08-20 14:29:08 UTC
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
Provides: foo
Obsoletes: foo 

Comment 2 Jeff Pitman 2004-08-26 16:01:44 UTC
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 ==> 
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): 
Let me know what Option you think is possible and the best for my 
Appreciate it, 

Comment 3 Rex Dieter 2004-08-26 16:50:06 UTC
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 

Comment 4 Jeff Pitman 2004-08-27 16:43:21 UTC
> 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. 

Comment 5 Jeff Pitman 2004-08-29 06:41:16 UTC
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: 
Run "rpmbuild -bb *spec". 
Download the "test.sh" script. 
As root Run ". ./test.sh" in the directory where the RPMS were 
This test fixture will allow one to observe the behavior of Obsoletes 
in an easier, controlled environment. 

Comment 6 Rex Dieter 2004-09-20 16:14:24 UTC
See also commentary in bug #111071 regarding the "it's a feature not a
bug" implicit Obsoletes.  (-:

Comment 7 Jeff Johnson 2004-09-20 16:17:18 UTC
I did not say "feature", I said that the behavior is indeed intended:

    This is the implemented and desired behavior, not gonna change.

Comment 8 Rex Dieter 2004-09-20 16:25:25 UTC
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?).

Comment 9 Axel Thimm 2004-12-22 03:11:56 UTC
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

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.

Comment 10 Axel Thimm 2004-12-25 19:14:47 UTC
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.

Comment 11 Jeff Pitman 2004-12-29 14:41:36 UTC
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.  

Comment 12 Jeff Johnson 2006-04-25 04:20:36 UTC
The as intended behavior is going to remain exactly as is in rpm.

Note You need to log in before you can comment on or make changes to this bug.