Thanks -- that clarified a lot of stuff for me.
Please see my replies inline:
On Mon, Jun 1, 2009 at 3:32 PM, Jeff Johnson <firstname.lastname@example.org> wrote:
>>======== snipped ======
> OK, I think I see what you want.
> Let me try to describe what rpm does while upgrading.
> First of all, during a single upgrade transaction, RPM
> distinguishes between the "installed" and "added" package sets.
> What you appear to miss (my guess from what you asked for)
> is that Obsoletes: is a directive applied to the "installed"
> set at the time the package that has the Obsoletes: is
> included in the "added" set. So Obsoletes: by itself will
> only cause an already "installed" package to be removed at
> one instance in time. There is no persistence, nor is Obsoletes:
> applied to the "added" set.
> What that likely means for your S0 -> S1 -> S2 -> S3
> state transitions induced by U1, U2, U3 carrier packages is
> that the N+1 U package must Obsolete: members that were
> installed at level N. I believe you wanted U at level N
> to have the Obsoletes:, and the Obsoletes: must be at level N+1 instead,
> because Obsoletes: is honored only at a single instance
> in time, and applied only against "installed", packages,
> and that's at the point where the N+1 transaction is being assembled.
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.
> 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
I would ideally like the upgrade to follow an optimized sequence
wherever possible, and a strict sequence if dependencies are
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"
> There's one other detail that must be mentioned as well. Any single
> 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?
- 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?
> So within the restriction of identically named packages, the transition from
> S0 -> S3 using a U3 carrier (i.e. with Requires:) will usually do an
> optimized transition, replacing all possible older versions with the
> identically named "newer" version. That's basically what I called
> an "optimized sequence". If you want a strict "sequence" then the installer
> _MUST_ go through U1 -> U2 to get to installing U3 because, in general,
> there will be multiple versions of identically named packages involved, and
> so multiple transactions must be constructed for strict sequencing.
> There are details with package re-naming that can be handled by expressing
> Obsoletes: differently. At least @rpm5.org,
> Obsoletes: /path/to/file
> Obsoletes: virtualprovide = E:V-R
> will erase the package that "contains" whatever matches, and so one can
> work around package renaming with Obsoletes: directives on contents if
> But I suggest trying to keep the packages identically named if at all
> possible, its a nightmare to debug upgrades when the namespace is in
> constant flux.
> I think you've got the usage case of Un having Requires: on the elements in
> the set of packages that constitutes a Sn-1 -> Sn transition.
That is correct.
> 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.
Received on Tue Jun 2 03:07:52 2009