Re: Ordering
On 8 Mar 1998, Manoj Srivastava wrote:
> Hi,
> >>"Jason" == Jason Gunthorpe <jgg@gpu.srv.ualberta.ca> 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
Reply to: