RPM

Comment 1 for bug 911746

Revision history for this message
Jeff Johnson (n3npq) wrote :

There are too many aspects to LOOP removal to
be dealt with in a single bug report. I could easily
spend several days writing up blueprints on the various
aspects of this problem and nothing will change.

So I will deal with ordering issues summarily and in a "process flow"
fashion that is most relevant to increasing the quality of a distro:

   Ordering issues are a prime candidate for distro level continuous integration
   automation:
       ==> so this bug will be attached to the rosa-continuous-integration blueprint
   The ordering issues are currently at a "detection" and assessment level, and
   CI will only increase the rate at which the issues are understood.

   Per Oyvind believes (and I do not) that certain rules might be implemented
   for automated LOOP breaking. The discussion so far is here
       http://rpm5.org/community/rpm-devel/4633.html
   "Been there, done that, dinna work." imho.

   rpm.org has fiddled up several changes to ordering, including using Tarjan's
   topological sort algorithm, and adding an OrderedBy: tag to provide additional
   hints to be used by tpmtsOrder(). The major advantage to the rpm.org algorithm
   is this:
       All LOOP's are eliminated before a topological sort is performed.
   Note that the rpm.org SCCS ("Strongly Connected Component Set") has already been
   ported into @rpm5.org, but cannot just be blindly used or enabled with explicit QA

There's a metric tonne butt load of other peripheral issues that I will ignore for now.

But in general
    Packaging needs to be changed to remove *all* LOOP's because its KISS.
is the right answer here. And automated CI will be the most effective means to
make that happen: RPM already has extensive "make Verify-FOO" QA tests that
need to be tied into an automated CI test harness to detect ordering issues.