Re: Getting rid of circular dependencies, stage 5

[Bruce Sass <bmsass@shaw.ca>]

On Tue July 25 2006 05:38, Goswin von Brederlow wrote:
> Except that libapt does NOT correctly handle dependency loops and can
> split them between dpkg calls causing install failures.
>
> The more circular depends there are the more likely such a failure
> becomes. So wouldn't it be a good thing to remove all the circular
> depends that are not neccessary?

Sure, but an even better thing would be to fix libapt.

It sounds pretty arbitrary of libapt to split an install into batches
based simply on size (assuming all the pre-depends, etc. have been
looked after), and it is just plain not right to place arbitrary
limits on the package archive because of failings in client software.

If that is the root of the problem with circular dependencies, and it 
has been known for years, why haven't any of the obvious fixes[1] been 
implemented?


- Bruce

[1] "obvious" fixes, imo:

- Heuristically remove potentially problematic packages from the batch.
  Eventually, either the afflicted packages will end up in the same
  batch or the last batch will be larger than what libapt wants to
  pass onto dpkg (the outcome of which is either the status quo or
  no-problem, depending mostly on how conservative the max size is on
  the target system.) The upside of this is that it is likely to be easy
  to implement as a filter function; the downside is that its
  inefficiency is magnified by the likelyhood of additional dpkg
  invocations.

- Build chunks based on the structure of the dependency tree of the
  packages being installed. E.g., the first batch sent to dpkg would
  consist of independent packages (which only depend on stuff already
  installed) depended upon by multiple packages, next would come chunks
  of packages with dependency relationships, finally the independent
  packages which couldn't be used to fill up prior batches. The upside
  is that it would be a very interesting (as in fun) project [recursion,
  graphs, packing, accommodating multiple chunk'n'batch strategies
  (because it is unlikely the same one would work "best" for daily
  upgrades from unstable -> yearly dist upgrades of stable)], maybe a
  DB, what more could a programmer want, eh]; the downside is that it
  may also be interesting in a "Chineses curse" kinda way
  [see: http://www.noblenet.org/reference/inter.htm].