Re: Ordering
On 8 Mar 1998, Manoj Srivastava wrote:
> Hi,
>
> The breaks process is also where we can implement a configure
> now mechanism. If some packages are marked as such (and judgment
> should be used in marking packages so), then a flag can be added to
> the package, and the unpack/intall routine can call the configuration
> routine at that point.
<sigh> You just found another bug.. There is no mechanism to assure that
pre-depends dependants dependants (etc) are installed before the
predepends, only that the pre-depends immediate dependants are unpacked.
Joy..
I was hoping to advoid this, but in that single case there is the
potential for a predepends+conflicts+depends loop! <arg>
Whatever scheme is used to fix this bug can be applied to immediate
configuration as well.
> This caould be used to make sure that mission critical
> packages are not left in unpacked-but-unconfigured state for too long
> (ungrading from Bo to Hamm can take a long time on a slower machine).
>
> Question: how are you handling dependency loops in the
> ordering algorithm? Actually, I shall cvs upgrade deity and check.
No, I just let them fall wherever, if there is a loop (ie that perl thing)
then it will have to be solved in some way external to the ordering code.
If there is a straight depends/configure loop then it is ignored, what can
you do?
The routine actually loops a considerable amount, this is caused by the
consideration of reverse depends and reverse provide depends, they tend to
bring out weak loops that are not very important. It also just occured to
me that reverses only need to consider conflicts and can ignore
pre-depends..
> I think that if there was a way of looking at the dependents
> (or reverse dependents) in a given order (pre-depends first, then
> depends, etc), that would make loop breaking easier, and less likely
> to mess up.
Yeah, I am going to run a configure order pass over the list in full and
then run a conflicts+predepends pass over the list in full. That should
provide a reasonable 'soft' depends ordering for unpacking.
> Also, optionally, if the user so desires, one could also try
> making sure that recommends were ordered earlier, but with a soft
> error flag that would abandon the node without coloring them if a
> loop dependency arose while in the soft dependency cycle (this is a
> bell and whistle)
Hm, again, run a recommends+depends ordering pass before the depends
before the conflits+predepends pass, that would take care of most problems
I think?
Jason
Reply to: