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.
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 -integration blueprint
automation:
==> so this bug will be attached to the rosa-continuous
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 rpm5.org/ community/ rpm-devel/ 4633.html
for automated LOOP breaking. The discussion so far is here
http://
"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.