On Apr 23, 2008, at 1:42 PM, devzero2000 wrote:

> Right to see if I am going in the right road, send you a  
> pathological  test for rhbz # 437041.
>
> I not have tested on 5.1, on 5.0.3 it fillup the bug.
>
> It create 500 packages, with many deps loop, produced by a random  
> process. The package
> are in depencency clousure.
>
>
> Hope it could be useful.
>

Generating packages with lots of random dependency loops
is (imho) exactly the right approach to insure coverage through
a test harness in general.

But automated testing also should try to provide some
details that cause the failure:

Here are the 2 largest flaws that I'm aware of with dependency loop &  
ordering:

1) all relations in a loop are ignored

     Ignoring all dependency relations in a loop, rather than just  
ignoring a single
     relation, is overkill. The Principle of Least Surprise says  
discard all relations
     in a dependency loop. However, better could be done, there are  
heuristics
     such as the number of incoming edges to a node that could be  
used to select
     which relation to ignore.

2) "batch" rather than "incremental" processing

     The package ordering in rpmtsOrder() is "batch" oriented. By  
"batch" I mean that
      a topological sort algorithm is run on a queue until  
termination, and then success/failure is checked.
      If there is a failure (because of dependency loops), then the  
dependency loop is corrected by
      ignoring relations, and the algorithm is restarted.

      There is a problem with a "batch" approach however. Other nodes  
may be processed before
       nodes that would be processed if there were no dependency  
loops. That is mathematically
       permitted, and is entirely consistent with "partial ordering".

      But in rpm terms, restarting tsort after dependency loops can/ 
will cause package erasures before
      installs. This leads to "stange" and "bizzarre" and  
"mysterious" bug reports that rpm is not behaving
      correctly when the root cause is often dependency loop ordering.

      One specific failure case is %config handling. A modified % 
config(noreplace) file will be renamed with
      extension .rpmsave under erase-before-install conditions, where  
the expectation is (often)
      that a modified %config(noreplace) file with extension .rpmnew  
will be installed. The renaming with extension
      .rpmsave, and the new package installing with .rpmnew, leaves  
no file installed, damons don't restart, etc, etc
      and so is the most often reported failure symptom.

      The "stange"ness comes because ordering (and loop handling) is  
the flaw, not the %config handling. And
      so attempts to reproduce the problem with smaller sets of  
packages invariably "work" because the
      erase-before-install behavior iisn't seen with smaller numbers  
of packages.

(aside) One part of the eventual fix will be "incremental" rather  
than "batch" handling. By "incremental"
I mean that packages will be ordered and closure will be checked when  
added, not as separate methods,
so that problems can be reported immediately, not delayed. There are  
are other parts of fixing too ...

I'd love to capture a reproducer for the erase-before-install issues  
with %config handling
  in a test harness somehow. My specific suggestions are to add a few  
%config(noreplace)
files to your loopordering-1.spec file, and perhaps tests  
on .rpmnew/.rpmorig/.rpmsave
files for the %config handling. The general approach building lots of  
packages with
dependency loops is perfectly fine.

73 de Jeff