RPM Community Forums

Mailing List Message of <rpm-users>

Re: 'Obsolotes' and 'Requires'

From: Jeff Johnson <n3npq@mac.com>
Date: Tue 02 Jun 2009 - 14:07:11 CEST
Message-id: <8F1A0B51-1780-4C6F-89BF-3CCCFC45497C@mac.com>

On Jun 1, 2009, at 9:07 PM, Anshuman Kanetkar wrote:
>
> I see. So if Un+1 Obsoletes: some packages from Un, these packages
> have to appear in the "installed" set when the N+1 upgrade transaction
> is created. Which basically means Un has to be installed as part of a
> separate transaction from the one that installs Un+1 if such
> dependencies are unavoidable.
>

Hmmm, I'm not sure how you arrive at a need for separate transactions  
here.

Separate transactions are needed iff some transaction needs multiple
instances of an identically named package. RPM will always substitute
the "newest" (by version comparison) instance, dropping "older"
instances.

>
>> The other detail that you may be missing (its hard to tell whether
>> you want a strict "sequence" through the intermediate Sn stages or
>> an optimized "sequence" that just jumps from S0 -> S3) is how
>> RPM upgrades "newer" packages. For packages with identical
>> names, RPM will eliminate all older versions, even multiple instances
>> with different versions, when upgrading to a "newer" package with  
>> the same
>> name.
>>
>
>
> I would ideally like the upgrade to follow an optimized sequence
> wherever possible, and a strict sequence if dependencies are
> explicitly specified.
>
> Consider the following example:
>
> U1 requries: p1.rpm
>
> U2 requires: p1'.rpm, p2.rpm, p3.rpm
>
> U3 requires: p1''. rpm, p2'.rpm
>                   ( p1'' requires p1' )
>                   ( p2' requires p3 )
>                   ( p2 obsoletes p3 )
>
> I would like the following behaviour if U3 is to be applied to a  
> system in S0):
>
> p1' is a prerequisite for p1''.(if p1' is not installed, p1' should
> first be installed and then upgraded to p1'' ).
>
> p2 is not a prerequisite for p2' (but p2' should upgrade p2 if it  
> exists)
>
> p3 is a prerequisite of p2', but p2' obsoletes p3. e.g. p2' depends on
> a side-effect of installing p3, but U3 does not require p3.
> (According to your reply on Obsoletes:, this cannot be part of the
> same transaction, because p3 would have to belong to the "installed"
> set).
>

Perhaps an example illustrates.

Initial state:	p1 installed.

Upgrade U2+U3:
     The "added" packages needed are
	p1', p2, p3	(from U2 requires)
	p1'', p2'	(from U3 requires)
     The transaction will substitute in the "added" set
	p1'' for p1'
	p2' for p2
     The older p1 package will be erased because p1'' is "newer"
     The Obsoletes: will look in the "installed" set and not find p3.
so the package operations will be
	+p1'' -p1 +p2' +p3

For a strict sequence, U2 then U3, p3 would be installed and then  
erased.
For the optimized U2+U3, p3 will be installed.




>> There's one other detail that must be mentioned as well. Any single
>> transaction
>> can have only a single package with a given name. If multiple  
>> versions of an
>> identical package are requested in a single name, then the "newest"  
>> package
>> will be used, older versions will be silently dropped from the  
>> transaction
>> and replaced with the "newest" version.
>>
>
> Does this hold even when a newer version explicitly "Requires:" an
> older version of the same package?
> i.e.
> - pkg-1.rpm requires pkg-2.rpm
> - Neither pkg-1.rpm  nor pkg-2.rpm are installed on the system.
> Would the requires assertion as shown in the example make a
> higher-level package manager such as Yum install the older version and
> then upgrade it with the newer version?
>

The issue is entirely with the composition of the "added" set. i.e.
no dependency assertions are checked or will affect adding
an "identical" package with same name.

Other attributes, like intended arch, are taken into account when
choosing which of 2 packages with same name will be included.
Bur dependencies are not used to make the choice.

>
>
>> All Requires:
>> are pre-requisites, not co-requisites, unless there are loops, in  
>> which case
>> the Requires: will be assertion checked, but the Requires: will be  
>> ignored
>> while ordering packages.
>>
>
> I understand that by this you mean that the "Requires:" tag is only
> checked once only against the set of installed packages, and is
> ignored while ordering packages if there are loops.
>

Yes. The Requires: can be satisfied by either "added" or "installed- 
but-not-erased"
packages. Basically closure after the upgrade is what is being verified.

73 de Jeff
Received on Tue Jun 2 14:07:39 2009
Driven by Jeff Johnson and the RPM project team.
Hosted by OpenPKG and Ralf S. Engelschall.
Powered by FreeBSD and OpenPKG.