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]. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
