Re: Getting rid of circular dependencies, stage 3
On Mon, Jan 09, 2006 at 10:15:58PM -0500, Joey Hess wrote:
> Bill Allombert wrote:
> > Here the lists of packages involved in circular dependencies listed by
> > maintainers.
> > Joey Hess <email@example.com>
> > debconf
> > debconf-english
> > debconf-i18n
> These are all necessary, and debconf is an essential package which is
> not subject to the circular dependency postinst ordering problems afaik.
> (You also never filed any bugs on these.)
Is it a request I report one ? I will if you want.
> > uqm
> > uqm-content
> The bug report for these does not give any concrete reasons why a
> circular dependency is a problem in this particular case.
I cannot point you exactly why _this_ circular dependency is going to
be a problem, no.
However I can point you to bug #310490 which show a woody system that
could not be upgraded to sarge without removing most of KDE.
This could be reproduced by install the following package on clean
konqueror aptitude libqt3 libhtml-tree-perl libapt-pkg-perl libft-perl
The analysis show that the problem was that in _woody_:
1) libqt3 has a circular dependency with libqt3-mt.
2) libhtml-tree-perl has a circular dependency with libwww-perl.
and that apt was not able to deal with that optimally. In the end we
were not able to fix the problem, because we could not fix woody and
sarge apt did not fare better anyway. The situation is too complex to
expect the software to make the optimal solution of what should be
removed to allow upgrade.
As the woody-to-sarge has shown we do not have enough time to fix the
upgrade problem during the freeze and testing is too much in a flux to
track them outside a freeze. The solution I propose is to do upgrade
tests regularly and simplify the dependencies. Some of the most severe
issues in the woody-to-sarge upgrade were due to circular dependencies
in _woody_. The fact we cannot fix problems in stable imply we have to
be careful to not introduce potential issues that will come back to
So maybe it is not a bug in the uqm package specifically, but it is still
a problem for Debian in the big picture.
If you have better suggestions how we can provide smooth upgrade between
stable releases without a six month freeze, I will be happy to work on
them. I am running a large scale upgrade test just now.
Imagine a large red swirl here.