On 8 Mar 1998, Manoj Srivastava wrote: > Hi, > >>"Jason" == Jason Gunthorpe <[EMAIL PROTECTED]> writes:
> 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. This is where I started. But it does not handle Removal very well, consider what the current algo does: Remv b0 i0 d1 getty Remv b0 i0 d2 libgdbm1-dev Remv b0 i0 d3 tcl76-dev Remv b0 i0 d4 ncurses3.0-dev Remv b0 i0 d5 libc5-dev Remv b0 i0 d6 libjpeg-dev Inst dpkg-ftp Remv b1 i1 d7 libnet [dpkg-ftp ] Remv b1 i1 d8 xarchie [dpkg-ftp ] Remv b1 i1 d9 xlib6-dev [dpkg-ftp ] Remv b1 i1 d10 xpm4.7-dev [dpkg-ftp ] Inst 9wm Inst adduser Inst ae Inst afterstep Inst base-files Inst base-passwd Inst libc5 Inst libc6 Inst ncurses3.4 Inst ldso Conf b5 i11 d10 base-files [adduser afterstep dpkg-ftp 9wm ae ] Conf b5 i11 d10 base-passwd [adduser afterstep dpkg-ftp 9wm ae ] Conf b5 i11 d10 ldso [adduser afterstep dpkg-ftp 9wm ae ] Conf b5 i11 d10 libc6 [adduser afterstep dpkg-ftp 9wm ae ] Conf b5 i11 d10 libc5 [adduser afterstep dpkg-ftp 9wm ae ] Conf b5 i11 d10 ncurses3.4 [adduser afterstep dpkg-ftp 9wm ae ] Notice it unpacked, but did not confugure dpkg-ftp to remove the dependancy on libnet so that libnet could be removed without a forcing option. Doing this with a single order pass did not work out. I think it is more flexable to do the two ordering stages, because it advoids most depends+predepends+conflicts loops (depends are ignored during unpacking) Hm, I never noticed this before but, it unpacked ldso after libc?, but configured it before.. The ldso in this system satisfies all the depends already.. also reversed the order of libc6/5 .. [ponder] I don't know if you know this, but dpkg does do configuration ordering, just not unpacking ordering... > 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. You can't because something may have been unpacked that cannot yet be configured, ie dpkg-ftp in the above example. You have to progressively consider each package to see if it's deps are now met. > 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) I think there are none in the conflicts+predepends (apart from perl) and loops in depends are not terribly relavent. > 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? I wouldn't be sure how to go about finding them to decide using your 2nd algorithm. > 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. Each pass orders different, the end result from a pass is a fully correct order for the requirements in the pass. By pre-ordering you take advantage of that fact that very few packages actually have conflicts+predepends that require attention. Now, the question of the day is: how do you handle the perl/perl-base loop? Can you just dpkg --remove perl;dpkg --install perl-base;dpkg --unpack perl; ? Doing autodeconfigure will probably cause problems, maybe we should use a --force option ro remove perl? Jason
