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

Re: Ordering



Okay, here we go..

First off I would like to make sure we both know the Rules of Dpkg, if you
recall we hit upon these when talking about libpaper and libpaperg on IRC
a bit back.

 1) Unpacking ignored Depends: on all packages
 2) Unpacking requires Conflicts: on -ALL- packages to be satisfied
 3) Unpacking requires PreDepends: on this package only to be satisfied
 4) Configuring requires that the Depends: of the package be satisfied
    Conflicts+PreDepends are ignored because 2,3 say they are already
    correct [exageration, it does check but we need not be concerned]
 5) Configuration requires that no Reverse depends are unsatisified

Dpkg does not check 5 but it is a logical extension. These rules are true
and are inviolatable.

Now, let us discuss what I have dubbed the Chimera Case, I hit upon it
when looking at the chimera package,

Current:
Chimera-1, Depends: elf-xlib
xlib6-1, Provides: elf-xlib

Install (Candidate):
Chimera-2, Depends: xlib6g
xlib6-2,
xlib6g-1, Conflicts: xlib6 (<< 2)

Here is the best order,
Inst Chimera
Inst xlib6
Inst xlib6g
Conf xlib6
Conf xlib6g
Conf Chimera

Notice the totaly different ordering of configure and unpacking. Chimera
is unpacked first to remove the dependancy on elf-xlib so that when the
new xlib6 is unpacked no configured packages are broken. -- This is a
feature and is not required by the Rules above. Here is a list of the
features I have considered to be valuable in Unpacking ordering

  f1) Unpacking a new package should advoid breaking dependancies of
      configured packages
  f2) The time a package spends unpacked should be minimized
  f3) Removal should not require a force, corrolory of f1
  f4) Unpacking should order by depends rather than fall back to random
      ordering.

These are very different from the requirements of Configure ordering. Let
us now examine some of the cases pkg-order had problems with using the
above rules + features.

Current:
libfoo1-1, Depends: libc5

Install (Candidate):
libfoo1-1.1, Depends: libc5
libfoo1g-1.1, Depends: libc6 Conflicts: libfoo1 (<< 1.1)
libfoo1g-dev-1.1, Depnds: libc6-dev, libfoo1g (= 1.1)

Order:
Inst libfoo1  [by Rule 2]
Inst libfoo1g 
Inst libfoo1g-dev [by Rule f4]
Conf libfoo1
Conf libfoo1g
Conf libfoo1g-dev

How about libpaper,
Current: 
libpaper-0.1, 

Install (Candidate):
libpaper-1, Depends: libpaperg
libpaperg-1, Conflicts: libpaper (<< 0.1)

Order:
Inst libpaper [by Rule 2]
Inst libpaperg
Conf libpaperg
Conf libpaper

So if you follow the rules listed you get valid, optimal unpacking orders.
There are considerably more complex cases that I have seen it handle
easially but the above few illistrate most of the key points.

The KEY thing to realize from this is that UnPacking Ordering !=
Configuration Ordering. They have very different goals.

Now, the derivations of these rules came about after extensive analysis of
what the simulator was saying, they produce the smallest number of broken
packages I have seen - in my bo->hamm upgrade tests all breaks have been
to unpacked packages, which is excellent! 

The best example of the Chimera Case (which is what led me to this whole
thing) is when many X packages are being upgraded, pure depends ordering
gives something like

Inst xlib6       [chimera xbill xboard]
Inst xlib6g      [chimera xbill xboard]
Inst chimera     [xbill xboard]
Inst xbill       [xboard]
Inst xboard
...

Things in [] are broken, configured packages. By following the rules you
get

Inst chimera
Inst xbill
Inst xboard
Inst xlib6
Inst xlib6g

No breaks!

Jason


Reply to: