Bruce Sass <bmsass@shaw.ca> writes:
> 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?
That usualy indicates that it is not trivial to do so.
> - Bruce
>
> [1] "obvious" fixes, imo:
The obvious fix would be to avoid the command line length limit by
using the dpkg FD feature.
> - 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.
When some cyclical depends overlap the set that needs to be done can
be rather large. It might be, and probably is, too large to split
simply from the list of to be installed packages. You most likely have
to go back to the resolver stage and find packages that can be kept
back for a round of installs to make sets smaller. Which means it is
complicated to do.
> - 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].
Apt already does that. Packages are sorted so that they are installed
in the order of depends or the splitting into multiple dpkg calls
would always fail.
The problem is that you have dependency cycles. That means when the
list of packages is sorted by their depends every now and then there
is one package that depends on a package later in the list (or in your
terms depends on the same batch). With cycles there is no possible
sorting that avoids that.
MfG
Goswin