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
