On Mon, Jul 24, 2006 at 05:12:54PM +0100, Ian Jackson wrote:
> Manoj Srivastava writes ("Re: Getting rid of circular dependencies, stage 5"):
> > Clearly, dpkg authors have read all of policy, including the
> > caveats about circular dependencies.
>
> This is particularly amusing given that that part of policy was
> (a) written by the dpkg authors (ie, me) and (b) was written as
> documentation for the actual behaviour (which was and is believed to
> be correct).
>
> Actually, there is room for improvement in the documentation here
> since it fails to mention that the cycle-breaker in dpkg looks to see
> which packages have postinst scripts so as to minimise the disruption
> due to disregarding one of the dependencies. I have just filed a bug
> about this :-).
Well, the problem with circular deps is not caused by dpkg but by the way
apt calls it:
0) in apt-0.6.44.2/apt-pkg/deb/dpkgpm.cc:483, the list of packages fed
into dpkg at the same time is blindly split into blocks not exceeding
MaxArgBytes (a number configurable in the apt.conf.) in length.
now imagine a very long "List" of packages (to which the iterator "I"
corresponds). Such as could happen in the case of
- apt-get dist-upgrade
- tools such as FAI's install_packages (which contains a workaround for
this bug now BTW)
For this bug to happen, the loose ends of a circular dep must end up in two
different blocks Block1 and Block2.
1) apt calls dpkg --unpack for each block of packages
(so far, no problem)
2) apt calls dpkg --configure for each block of packages
- now dpkg barfs, as it can only handle circular deps with both ends in
one block.
Due to the boundary conditions
- long package list (concatenated filenames exceeding MaxArgBytes)
- split must happen in the middle of a circular dep
this bug is very hard to reproduce, but caused already a lot of headaches.
Furthermore, the apt source is not exactly easy to understand.
I reported this about 3 years ago to the apt people, together with a
proof-of-concept patch/hack making apt control dpkg using --command-fd
to get around the maximum-command-line-length limit.
This patch was rejected, as it lacked error-checking exceeding the present
one.
Instead, the variable MaxArgBytes was introduced instead of some number
that was hardcoded in this place. Well, not exactly a solution for the
problem, but you should now be able to more easily reproduce it by
lowering MaxArgBytes in apt.conf ;)
--
c u
henning
signature.asc
Description: Digital signature
