[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: