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