On Feb 1, 2011, at 1:06 PM, Jeff Johnson wrote:
>
> I think you're crazy attempting prioritized package ordering. ;-)
>
Your conception of "priority" isn't the right design imho. For starters,
there's all sorts of legacy compatibility issues buried here:
+ static const evrFlags orderPriority[] = {
+ RPMSENSE_MISSINGOK,
+ RPMSENSE_SCRIPT_VERIFY,
+ RPMSENSE_PACKAGE,
+ RPMSENSE_FIND_REQUIRES,
+ _ERASE_ONLY_MASK,
+ _INSTALL_ONLY_MASK,
+ _ALL_REQUIRES_MASK
+ }; /* dependency to zap in order to try resolve dependency loops */
There are several better approaches.
The approach taken @rpm.org is to remove all LOOPS first. That relies
on Tarjan's algorithm and uses Strongly Connected Component's (SCC's)
as a natural ordering priority, no additional input is needed.
(aside)
But @rpm.org is choosing to fiddle about with Newer! Better! Bestest!
markup in order to get Tresys "collections" deployed, and to service
Peter Jones on the anaconda team who wants some means to ensure
that initrd creation is reliable. None of that crap is the right
thing to do unless you work @redhat.com.
You can plug in the @rpm.org Tarjan solution by changing this vectore
in lib/order.c:
int (*rpmtsOrder) (rpmts ts)
= _rpmtsOrder;
Exercise left to the hacker (and you WILL be working at cross purposes
with other "features" like using parentdir/linkto relations for ordering
already under way @rpm5.org).
With the existing @rpm5.org code, you are better off deciding
Which relation in a LOOP needs to be ignored?
This is in zapRelation() which -- a priori principle of fairness, nuke 'em all
--
ignores _ALL_ relations in a LOOP. Only one really needs to be ignored,
and before we get to grandiose implementations of "priority" used
for ordering (which will have all sorts of failure modes, just watch
what happens as rpm-4.9.1 is deployed, there will be endless permutations
and hacks added to stabilize Tresys "collections", its already happening ...)
Just FYI: The eventual "forward" looking solution @rpm5.org is gonna
be to just scrap rpmtsOrder() and replace with an incremental topological
sort done as a side effect of adding an install/erase package to a
transaction, and with LOOP detection and other problems available
immediately, not when a depsolver chooses to call rpmtsOrder().
But that will take some time/care to implement, nooone frigging cares
about RPM as long as RPM Just Works. Ditto rpmtsCheck(), which
also needs to be done incrementally as a side effect of adding an install/erase
element, not as a distinguished method. So rpmtsCHeck() is also destined
to be scrapped, just like rpmtsOrder(), @rpm5.org.
hth
73 de Jeff
______________________________________________________________________
RPM Package Manager http://rpm5.org
Developer Communication List rpm-devel@rpm5.org
