Re: Getting rid of circular dependencies, stage 5
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 been
 "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
- 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