Re: Ordering
Hi,
>>"Jason" == Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> writes:
Jason> 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.
Jason> You just found another bug.. There is no mechanism to assure
Jason> that pre-depends dependants dependants (etc) are installed
Jason> before the predepends, only that the pre-depends immediate
Jason> dependants are unpacked. Joy..
I think you need to have another layer in between ordering and
execution.
Let the ordering order all the unpacks and pass the list to a
post processing step.
When it gets there, evrything is in the correct order: even
the predependents dependents dependents ad infinitum.
Now, start unpacking, looking for flags. As soon as you hit a
configure now package (maybe becuase it is essential), you configure
everything to that point.
If the ordering succeded, then all the dependent of dependent
havbe been unpackaged. If there was a loop, it should be detected
here (re-visiting a black node, I think).
No fuss, no muss. Continue as before.
Jason> I was hoping to advoid this, but in that single case there is
Jason> the potential for a predepends+conflicts+depends loop! <arg>
I think we can try and see how many such loops exist (apart
from the Perl loop)
Jason> Whatever scheme is used to fix this bug can be applied to
Jason> 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.
Jason> No, I just let them fall wherever, if there is a loop (ie that
Jason> perl thing) then it will have to be solved in some way external
Jason> to the ordering code. If there is a straight depends/configure
Jason> loop then it is ignored, what can you do?
Try and ignore the edge that is least critical? like ignore an
extra package in favour of a important package?
Jason> The routine actually loops a considerable amount, this is
Jason> caused by the consideration of reverse depends and reverse
Jason> provide depends, they tend to bring out weak loops that are not
Jason> very important. It also just occured to me that reverses only
Jason> need to consider conflicts and can ignore pre-depends..
Correct, I think.
>> 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.
Jason> Yeah, I am going to run a configure order pass over the list in
Jason> full and then run a conflicts+predepends pass over the list in
Jason> full. That should provide a reasonable 'soft' depends ordering
Jason> 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)
Jason> Hm, again, run a recommends+depends ordering pass before the
Jason> depends before the conflits+predepends pass, that would take
Jason> care of most problems I think?
Before? I am confused. Each pass gets more strict? I have to
examine the multiple passes better.
manoj
--
"For a male and female to live continuously together is...
biologically speaking, an extremely unnatural condition." Robert
Briffault
Manoj Srivastava <srivasta@acm.org> <http://www.datasync.com/%7Esrivasta/>
Key C7261095 fingerprint = CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
Reply to:
- Follow-Ups:
- Re: Ordering
- From: Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>
- References:
- Re: Ordering
- From: Jason Gunthorpe <jgg@gpu.srv.ualberta.ca>