On Jul 18, 2008, at 3:37 PM, Jay Soffian wrote:

> On Fri, Jul 18, 2008 at 2:39 PM, Jeff Johnson <n3npq@mac.com> wrote:
>> Again, the better fix is to rebuild the vendor package, and add
>>    Requires: pre-vendor
>> but politics, not engineering have ruled out that solution, and so
>> hacks-r-us is all that can be attempted.
>
> Okay, thanks for the suggestion.
>
>> I haven't a clue what is surprising to you, you have neglected to  
>> state what
>> the surprise is or was.
>
> I specified on the command-line:
>
> $ sudo rpm -U foo-1-0.x86_64.rpm bar-1-0.x86_64.rpm baz-1-0.x86_64.rpm
>

Apologies, I missed the instructions. I've attached a somewhat  
simpler foo.spec howvere.

> Yet the installation order appeared to be: baz, foo, bar.
>

I've reproduced here. Here's -Uvv with the CLI
     sudo rpm -Uvv foo-1-0.i386.rpm bar-1-0.i386.rpm baz-1-0.i386.rpm

Yah the ordering is surprising:

D: ========== recording tsort relations
D: ========== tsorting packages (order, #predecessors, #succesors,  
tree, Ldepth, Rbreadth)
D:     0    0    0    3    0    0 +baz-1-0.i386
D: ========== successors only (1480 bytes)
D:     1    0    0    1    0    1 +foo-1-0.i386
D:     2    0    0    2    0    2 +bar-1-0.i386


Here's the likely explanation (I can dig deeper if necessary)

Packages are processed as encountered, which is same as CLI ordering.

When packages with no prerequisites are queued, and the number of  
incoming edges
is identical in this case 0, then the decision to queue is arbitrary.

rpm appears to do LIFO when initializing the queue. FIFO is what you  
are expecting.

Which means the last node queued is processed first: in this case "baz".

After a node is processed, rpm checks to see whether the remaining  
packages
can just be emitted. Since there are no dependencies, the remaining  
packages are emitted
in FIFO order.

So my guess (I'll check in a moment) is that the last package is  
permuted before all
other packages specified on the CLI.

Checking ... yah, LIFO then FIFO for the remainder ...

[jbj@wellfleet foo]$ sudo rpm -Uvv bar-1-0.i386.rpm baz-1-0.i386.rpm  
foo-1-0.i386.rpm


...

D: ========== recording tsort relations
D: ========== tsorting packages (order, #predecessors, #succesors,  
tree, Ldepth, Rbreadth)
D:     0    0    0    3    0    0 +foo-1-0.i386
D: ========== successors only (1496 bytes)
D:     1    0    0    1    0    1 +bar-1-0.i386
D:     2    0    0    2    0    2 +baz-1-0.i386

..

Either FIFO or LIFO could be used, that's "partial ordering".

The other ordering which I did not mention is anaconda, or  
"presentation"
ordering. Instead of using the no. of incoming edges as an "importance"
heuristic, the CLI order is used instead.

So here's the order with --anaconda added

[jbj@wellfleet foo]$ sudo rpm -Uvv --anaconda bar-1-0.i386.rpm  
baz-1-0.i386.rpm foo-1-0.i386.rpm

...

D: ========== recording tsort relations
D: ========== tsorting packages (order, #predecessors, #succesors,  
tree, Ldepth, Rbreadth)
D:     0    0    3    1    0    0 +bar-1-0.i386
D: ========== successors only (1480 bytes)
D:     1    0    2    2    0    1 +baz-1-0.i386
D:     2    0    1    3    0    2 +foo-1-0.i386

which is likely what you were expecting in the first place.


> My first surprise is that the RPMs appear to have been installed in a
> different order than I specified on the command line. Since these RPMs
> have no interdependencies, why should they be re-ordered? My second
> surprise is that "--noorder" didn't appear to have any effect (i.e.
> the RPMs still appeared to be installed in a different order than I
> specified on the command line).
>

With --noorder, the internal store of Provides: and files is not  
created,
hence there are no edges possible in the dependency graph, no Requires:
will ever find a Provides: in an empty store.

So everything else is as before, LIFO to initialize the queue, after  
1st node
is processed, remaining elements are emitted in FIFO order.

And you are still welcome to switch to @rpm5.org any time you choose ;-)

73 de Jeff