Re: Getting rid of circular dependencies, stage 3
On Wed, Jan 11, 2006 at 09:34:27PM -0500, Joey Hess wrote:
> > 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.
>
> I've read that bug before and I appreciate the time you've spent in
> chasing down these upgrade issues but I think you're generalising too
> far from that bug to a conclusion that any given trivial dependency loop
> will cause similar problems.
>
> > 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.
>
> Although sarge's aptitude did..
I don't know, there were no ways to upgrade to sarge's aptitude.
> > The situation is too complex to
> > expect the software to make the optimal solution of what should be
> > removed to allow upgrade.
>
> I'm not so sure, have you seen the work that's been done recently on
> aptitude's problem resolver?
After sarge released ? no. However the upgrade path of aptitude itself
is problematic. We should probably provide a statically linked
(at least the C++ libs) to ease upgrade.
In my current sarge to etch upgrade test, I installed the first 1000
packages by alphabetic order (minus conflicts, plus dependencies)
and tried to upgrade. aptitude dist-upgrade give:
The following packages will be REMOVED:
abiword-doc acl2 acl2-books acl2-emacs acl2-infix akregator-i18n
akregator-konq-plugin akregator-kontact-plugin alex alsa-headers amarok
amarok-arts amarok-engines amarok-gstreamer amarok-xine aqsis aqsis-libs
aqsis-libs-dev ardour-gtk aspell-bin aspell-br aspell-cy aspell-da
aspell-de aspell-de-alt aspell-el aspell-en aspell-es aspell-fi aspell-fo
aspell-fr aspell-ga aspell-gl-minimos aspell-is aspell-it aspell-lt
aspell-nl aspell-no aspell-pl aspell-pt aspell-pt-br aspell-sk aspell-sl
aspell-sv aspell-tl aspell-ukr axiom axiom-graphics axiom-hypertex
axiom-test basket beecrypt2 beecrypt2-dev bibletime bibletime-i18n
bitscope brahms capplets castle-combat-data caudium-pixsl cduce g77-3.3
gdk-imlib1-dev ghc5 jackd kdelibs4 lam4 libafterstep0 libaiksaurus-data
libaiksaurus0c102 libaiksaurusgtk0c102 libardour0 libarkrpg libarts1
libclalsadrv libconfigwin-ocaml-dev libcurl3-dev libenchant1 libfam0c102
libfltk1.1c102 libgengameng4 libglibmm-2.4-1 libgmp3
libgpattern-ocaml-dev libgtkmm-2.4-1 libgtkmm1.2-0 libgtkmmext0
libgtop2-2 libid3-3.8.3 libjack0.80.0-dev libkcal2a libkdenetwork2
libkdepim1 liblablgtk-ocaml liblablgtk-ocaml-dev libmagick++6
libmlchat-ocaml-dev libmodplug0 libmpich1.0 libmyspell3
libocamlcvs-ocaml-dev libokey-ocaml-dev libopenexr2 liboptions-ocaml-dev
libopts9 libopts9-dev libosp4 libostyle1 libplot2 libpstoedit0
libqt3c102-mt libreport-ocaml-dev libsigc++-2.0-0 libsoundtouch1 libsp1
libtag1 libtiffxx0 libwpd-stream8 libwpd8 mlchat ocaml-ioxml ocaml-omom
ocaml-zoggy odbcinst1
After unpacking 150MB will be freed.
This look like a bit much.
(actually aptitude while try to remove 11 packages more than apt-get).
Simply upgrading aptitude cause adduser-ng to be removed.
> > So maybe it is not a bug in the uqm package specifically, but it is still
> > a problem for Debian in the big picture.
>
> Filing scattershot but reports with no useful justifications might
> result in enough people going ahead and making changes to make it seem
> worth your time to do so, on the presumption that one of the changes
> will avoid some real problem, but please realize that you run the risk
> of annoying people when you do it.
For that reason I only reported one single bug by maintainers, unless when
maintainers asked me to do otherwise. My experience is that reporting
bugs always annoy people and that the price to pay to do quality
assurance.
However, that is a fair remark. I decided to go ahead because circular
deps have others drawback so I am not completly wasting everybody time
Do you have other ideas how we can provide smooth sarge to etch upgrade ?
I am not happy with the woody to sarge upgrade path. I did test months
before the freeze but there was simply too much flux in testing to be
conclusive. When sarge finally freeze, upgrade tests got much smoother
(and reproducible) but there was not enough time to really fix the
issues.
Now, I am experimenting with new kind of tests but transforming the raw
results to useful advices to improve the upgrade path is not obvious.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: