Re: Getting rid of circular dependencies, stage 6

[Goswin von Brederlow <brederlo@informatik.uni-tuebingen.de>]

Frank Küster <frank@debian.org> writes:

> Don Armstrong <don@debian.org> wrote:
>
>> On Tue, 24 Oct 2006, Petter Reinholdtsen wrote:
>>> [Ian Jackson]
>>> > The only argument I've heard against circular dependencies as a
>>> > general rule is that they can trigger a particularly stupid (and
>>> > probably not very hard to fix) bug in apt,
>>> 
>>> You seem to have missed the argument that packages with circular
>>> dependencies are impossible to install and configure in the correct
>>> (dependency) order, and thus will end up being installed and
>>> configured in a nondeterministic order instead. It is documented
>>> that dpkg try its best to find a sensible order for the packages,
>>> but it is bound to fail one way or another if two packages really do
>>> need each other to be configured before they are configured.
>>
>> Packages which have circular dependencies and depend on the other
>> package being configured are buggy; at most they can depend on the
>> other package being unpacked. Since there is no way to specify this
>> kind of dependency, Depends: is as close as you can get.
>
> It seems to me that the solution in such situation shouldn't be a
> circular dependency with its "nondeterministic" behavior, but instead to
> separate one of the packages into two.  For example if package b needs
> package a unpacked, but not configured, separate package a in a-data and
> a-therest, where a-data provides all that package b needs: Now b can
> depend on a-data, and a-therest can depend on b.
>
> Regards, Frank

You can have an arch:any package and arch:all package that depend on
each other. It can also not make sense to further split them due to
size.

Now say that the depends is only that at usage time some binaries need
shared scripts and the shared scripts need arch specific data (closing
the depends cycle). No dependency is there when configuring. It is
perfectly save for dpkg to break the cycle at any point.

Should there really be a further package split with a few K big
package?


The only problem with such cycles is that apt screws up its ordering
and cycle breaking and sometimes tries to configure A without B, which
dpkg then refuses. Maybe someone should fix apt to use the command-fd
interface to dpkg to get rid of the command line length limit that
causes this random spliting of cycles.

Some cycles are better left as such.

MfG
        Goswin