Re: Ordering
On 8 Mar 1998, Manoj Srivastava wrote:
> Jason> Notice it unpacked, but did not confugure dpkg-ftp to remove
> Jason> the dependancy on libnet so that libnet could be removed
> Jason> without a forcing option. Doing this with a single order pass
> Jason> did not work out. I think it is more flexable to do the two
> Jason> ordering stages, because it advoids most
> Jason> depends+predepends+conflicts loops (depends are ignored during
> Jason> unpacking)
>
> I don't understand this. What are the two passes again?
Unpacking and Configuration, at this point I am resonably convinced that
you cannot mix them :<
> >> 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.
>
> Jason> You can't because something may have been unpacked that cannot
> Jason> yet be configured, ie dpkg-ftp in the above example. You have
> Jason> to progressively consider each package to see if it's deps are
> Jason> now met.
>
> This is bad. If I understand you correctly, this is an
> accident waiting to happen (but I may very easily be just very
> confused)
Well, what sort of bad things can happen? I don't see how delaying a
configuration further is bad.
> Eiher the packages are ordered for install, or they are
> not. If they are not yet ordered, do no unpack anything.
They are ordered for UNPACK which means that conflicts and predepends are
valid at all points during the install.
> If they are indeed ordered, then yuo can stop at any point and
> configure everything upto that point; with the exception of a
> conflicts depends loop, which requires forcing.
No, because you might have had to re-oder things that cause a
depends+predepends+conflicts loop to junk the depends loop (ie your loop
detection) This will create a situation where an unpacked package cannot
be immedately configured - even your proprosed algorithm has to have this
problem.
> Jason> I wouldn't be sure how to go about finding them to decide using
> Jason> your 2nd algorithm.
>
> You do this implicitly, by descending the children in the
> order of importance of the dependency. So you try descending
> predepends first, then you decend depends links, and optionally the
> weaker relationships can be descended.
Hm, interesting idea, might have to do that, trouble is that
pre-depends+conflicts are ALWAYS important, they cannot be viloated, dpkg
will not allow it.
> Jason> Each pass orders different, the end result from a pass is a
> Jason> fully correct order for the requirements in the pass. By
> Jason> pre-ordering you take advantage of that fact that very few
> Jason> packages actually have conflicts+predepends that require
> Jason> attention.
>
> You can not actually take action on a conflicts/predepends
> pass, since you can have ordered the packages in an order that can
> not be installed.
No, the order before conflicts+predepends gets to it is irrelevent, by
ordering before you simply increase the probability that packages are in a
good configure order. I actually am now using a installation ordering
scheme that orders things in a good install order before the conflicts
loop. This produces a totaly different look, ie if you are upgrading
xlib+many x packages it will upack the x packages first and then upack
xlib and then do the reverse for configuation. That minimizes the breakage
to existing packages because they are all deconfigured before the break
happens. I'll clip in an ordering once I have tested it somemore, still
have to figure out how to detect removal+conflicts loops <sigh>
Jason
Reply to: