Re: Getting rid of circular dependencies, stage 3
Joey Hess wrote: Bill Allombert wrote: Although sarge's aptitude did.. I don't know, there were no ways to upgrade to sarge's aptitude. The bug log contains a log of astronut doing the upgrade with sarge's aptitude.. I think the bigger problem is not whether it's possible to do this (which it somewhat was) but that it's not intuitive and that it would require research for someone to figure out how to do. Perhaps there should be some kind of upgrade pseudo-package created to ease the transition, that depends on the tools needed? Ie, aptitude install etch-upgrade would install the later version of aptitude, etc. needed for the upgrade. Benjamin (astronut) signature.asc Description: OpenPGP digital signature
Re: Getting rid of circular dependencies, stage 3
Le jeudi 12 janvier 2006 à 21:12 +0400, Stepan Golosunov a écrit : Looking at them, I fail to see why debconf-i18n has to depend on debconf. Because /usr/share/doc/debconf-i18n is a symlink? Then this is something that can easily be fixed. Not as easily as with the classical foo - foo-data dependency, as debconf-english has the same symlink, but it's possible to keep these directories in the package. Gaining a few kilobytes on the hard disk to have the changelog in another package, at the cost of a circular dependency, is too expensive IMHO. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Getting rid of circular dependencies, stage 3
Adrian von Bidder [EMAIL PROTECTED] writes: From a graph algorithm point of view, if I'm not very mistaken, dependencies being guaranteed to be a directed graph instead of a generic graph should allow some simplifications/efficiency improvements in apt and other tools, too. For the record, dependencies are a directed graph by nature. Preventing circular dependencies will get you a directed acyclic graph (DAG) which is, IMHO, easier to handle. HTH -- Dominique Dumont Delivering successful solutions requires giving people what they need, not what they want. Kurt Bittner -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Friday 13 January 2006 16:53, you wrote: Adrian von Bidder [EMAIL PROTECTED] writes: From a graph algorithm point of view, if I'm not very mistaken, dependencies being guaranteed to be a directed graph instead of a generic graph should allow some simplifications/efficiency improvements in apt and other tools, too. For the record, dependencies are a directed graph by nature. Preventing circular dependencies will get you a directed acyclic graph (DAG) which is, IMHO, easier to handle. Arrgh. Of course, just a confusion of terms. cheers -- vbi -- F: Was ist ein Pensch? A: Das mittlere Stück von einem Lam-pensch-irm pgp7OK8BFipey.pgp Description: PGP signature
Re: Getting rid of circular dependencies, stage 3
Bill Allombert wrote: Although sarge's aptitude did.. I don't know, there were no ways to upgrade to sarge's aptitude. The bug log contains a log of astronut doing the upgrade with sarge's aptitude.. -- see shy jo signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
Henning Glawe wrote: To illustrate the scenario: - Package A depends on package B, which in turn depends on A 0) User calls 'apt-get install long-list-of-packages1 A B long-list-of-packages2': 1) apt splits the whole list into smaller parts after sorting by dependency where, in case this bug occurs: part1=long-list-of-packages3 A part2=B long-list-of-packages4 2) apt calls 'dpkg --unpack' for each element of part1 and part2 == so far no problem == 3) apt calls 'dpkg --configure part1' and 'dpkg --configure part2' where the first step already fails, because B is not in part1, but A depends on B == complete failure, user has to recover manually: debconf will not break in this situation (BTW, it's not formally essential, but it needs to have the same qualities as essential packages, and does.) -- see shy jo signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
On Fri, Jan 13, 2006 at 03:57:57PM -0500, Joey Hess wrote: Bill Allombert wrote: Although sarge's aptitude did.. I don't know, there were no ways to upgrade to sarge's aptitude. The bug log contains a log of astronut doing the upgrade with sarge's aptitude.. Yes, but only after having run 'aptitude install aptitude perl' with woody aptitude which did: 56 packages upgraded, 64 newly installed, 5 to remove and 547 not upgraded. which was a non trivial upgrade. So sarge aptitude was actually running on a smaller set of packages where the perl modules cicular-dep was no more present. 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]
Re: Getting rid of circular dependencies, stage 3
* Joe Smith | Joey Hess [EMAIL PROTECTED] wrote in message | news:[EMAIL PROTECTED] | | Joey Hess [EMAIL PROTECTED] | 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. | | Well, I'm not sure if that is an excuse for violating policy. Essential: yes packages must work while unconfigured, so they won't be bitten by the bug in question here. -- Tollef Fog Heen,''`. UNIX is user friendly, it's just picky about who its friends are : :' : `. `' `- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
Le jeudi 12 janvier 2006 à 01:49 +0100, Jeroen van Wolffelaar a écrit : At the very least, I think they should be treated like pre-depends, with a request on this list being mandatory before adding a circular dependency. Until now, all circular dependencies cases I have met were fixable. At first, some of them looked necessary and they required quite some work, but they were fixable. You know when you're adding a pre-depends. You're typing the word Pre-Depends in a debian/control file. You don't know when you're introducing a circular depends that easily, and it could be either of the packages in the circle that shouldn't have such a depends, not necessarily the last one that closed the circle should change. Sure, and I agree Bill's checks should go on. However, looking at the list, a vast majority of circular dependencies come from the same source package. This could be checked e.g. by lintian. -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Getting rid of circular dependencies, stage 3
Le lundi 09 janvier 2006 à 22:15 -0500, Joey Hess a écrit : Bill Allombert wrote: Here the lists of packages involved in circular dependencies listed by maintainers. Joey Hess [EMAIL PROTECTED] 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. Looking at them, I fail to see why debconf-i18n has to depend on debconf. Wouldn't it possible to just remove this dependency? Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Getting rid of circular dependencies, stage 3
On Thu, Jan 12, 2006 at 09:01:58AM +0100, Tollef Fog Heen wrote: | These are all necessary, and debconf is an essential package which is | not subject to the circular dependency postinst ordering problems afaik. | | Well, I'm not sure if that is an excuse for violating policy. Essential: yes packages must work while unconfigured, so they won't be bitten by the bug in question here. They could be bitten by this bug. Or speaking more accurately: they can make apt be bitten by this bug. The problem is not that they are not working; the problem is that apt breaks lists of to-be-configured packages at arbitrary points, which depend only on the list length; while dpkg can only handle circular dependencies if all elements of the circular dependency are passed to it at the same time. To illustrate the scenario: - Package A depends on package B, which in turn depends on A 0) User calls 'apt-get install long-list-of-packages1 A B long-list-of-packages2': 1) apt splits the whole list into smaller parts after sorting by dependency where, in case this bug occurs: part1=long-list-of-packages3 A part2=B long-list-of-packages4 2) apt calls 'dpkg --unpack' for each element of part1 and part2 == so far no problem == 3) apt calls 'dpkg --configure part1' and 'dpkg --configure part2' where the first step already fails, because B is not in part1, but A depends on B == complete failure, user has to recover manually: a) dpkg --configure -a b) goto 0 -- c u henning signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
On Thu, Jan 12, 2006 at 09:26:26AM +0100, Josselin Mouette wrote: Le jeudi 12 janvier 2006 ? 01:49 +0100, Jeroen van Wolffelaar a ?crit : At the very least, I think they should be treated like pre-depends, with a request on this list being mandatory before adding a circular dependency. Until now, all circular dependencies cases I have met were fixable. At first, some of them looked necessary and they required quite some work, but they were fixable. You know when you're adding a pre-depends. You're typing the word Pre-Depends in a debian/control file. You don't know when you're introducing a circular depends that easily, and it could be either of the packages in the circle that shouldn't have such a depends, not necessarily the last one that closed the circle should change. Sure, and I agree Bill's checks should go on. However, looking at the list, a vast majority of circular dependencies come from the same source package. This could be checked e.g. by lintian. This is lintian wishlist item #316283. 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]
Re: Getting rid of circular dependencies, stage 3
On Thu, Jan 12, 2006 at 09:30:56AM +0100, Josselin Mouette wrote: Le lundi 09 janvier 2006 à 22:15 -0500, Joey Hess a écrit : Bill Allombert wrote: Here the lists of packages involved in circular dependencies listed by maintainers. Joey Hess [EMAIL PROTECTED] 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. Looking at them, I fail to see why debconf-i18n has to depend on debconf. Because /usr/share/doc/debconf-i18n is a symlink? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Thu, Jan 12, 2006 at 09:12:27PM +0400, Stepan Golosunov wrote: Looking at them, I fail to see why debconf-i18n has to depend on debconf. Because /usr/share/doc/debconf-i18n is a symlink? perhaps the link should be the other way round. for example the most common package split would be something like: foo --depends-- foo-common if you want one doc dir for it, then of course the real directory has to be in foo-common, and the link in foo. cu robert -- Robert Lemmen http://www.semistable.com signature.asc Description: Digital signature
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. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Thu, Jan 12, 2006 at 11:49:14AM -0600, Bill Allombert wrote: 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. What does aptitude give as the breakdown between unused packages being automatically removed, and packages being removed that you actually requested installed? In spite of the large number of packages removed, almost all of these are packages that are not in etch... From a-c, only these packages are in your removal list and also in testing at present: ardour-gtk aspell-br aspell-cy aspell-da aspell-de aspell-de-alt aspell-el aspell-en aspell-es aspell-fi 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-ukr bitscope caudium-pixsl So, counting the aspell issue as one, that looks like a total of 4 upgrade problems. Which is four too many, but not as bad as it looks based on the output alone. :) -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
What does aptitude give as the breakdown between unused packages being automatically removed, and packages being removed that you actually requested installed? Well I did not install any packages through aptitude. The numbers of packages below the lines The following packages will be automatically REMOVED: and The following packages will be REMOVED: are the same. In spite of the large number of packages removed, almost all of these are packages that are not in etch... From a-c, only these packages are in your removal list and also in testing at present: ardour-gtk aspell-br aspell-cy aspell-da aspell-de aspell-de-alt aspell-el aspell-en aspell-es aspell-fi 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-ukr bitscope caudium-pixsl So, counting the aspell issue as one, that looks like a total of 4 upgrade problems. Which is four too many, but not as bad as it looks based on the output alone. :) Well, that, and why I still cannot deal with aptitude. Thanks for you review! Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Mon, Jan 09, 2006 at 10:15:58PM -0500, Joey Hess wrote: These are all necessary, and debconf is an essential package which is not subject to the circular dependency postinst ordering problems afaik. [...] The bug report for these does not give any concrete reasons why a circular dependency is a problem in this particular case. every circular dependency is a problem: the apt-dpkg-combo blows up as soon as apt splits the to-be-configured list for dpkg between the elements of a circular dependency. this happens, if apt is processing many packages at the same time, e.g. when run from an automatic installer like FAI (whose install_packages script has been equipped with a only-feed-N-packages-at-the-same-time-into-apt workarouns) or when doing a dist-upgrade between two debian releases on a machine with 'many' packages installed. conclusion: we have two possibilities a) explicitely forbid circular dependencies in policy b) explicitely allow them and enhance APT. a long time ago, O(2years), I wrote a hack to let apt and dpkg communicate via a pipe using dpkg's command-fd option; it was rejected at that time because the apt maintainers wanted to switch to a kind of libdpkg. Any news on this solution? -- c u henning signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
Le mercredi 11 janvier 2006 à 10:10 +0100, Henning Glawe a écrit : a) explicitely forbid circular dependencies in policy At the very least, I think they should be treated like pre-depends, with a request on this list being mandatory before adding a circular dependency. Until now, all circular dependencies cases I have met were fixable. At first, some of them looked necessary and they required quite some work, but they were fixable. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom
Re: Getting rid of circular dependencies, stage 3
On Wed, Jan 11, 2006 at 11:15:35AM +0100, Josselin Mouette wrote: Le mercredi 11 janvier 2006 à 10:10 +0100, Henning Glawe a écrit : a) explicitely forbid circular dependencies in policy At the very least, I think they should be treated like pre-depends, with a request on this list being mandatory before adding a circular dependency. Until now, all circular dependencies cases I have met were we should _only_ allow circular deps when apt handles them. otherwise they should be forbidden. the problems caused by this breakage are of cause fixable if you are running apt interactively and you know how to work around this problems (i.e. running apt with manually splitted package lists). but this causes a lot of trouble and is unusable in the non-interactive case. a simple fix for apt would be to run 'dpkg --configure --pending' to catch all the unpacked-but-not-configured packages instead of 'dpkg --configure some-part-of-a-list' explicitely. -- c u henning signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
On Monday 09 January 2006 19:20, Bill Allombert wrote: Here the lists of packages involved in circular dependencies listed by maintainers. Just wondering why this wasn't mentioned yet: aren't circular dependencies causing more work for RM's, too, because the testing migration script can't handle dependencies loops autmatically in some/most/all cases? From a graph algorithm point of view, if I'm not very mistaken, dependencies being guaranteed to be a directed graph instead of a generic graph should allow some simplifications/efficiency improvements in apt and other tools, too. cheers -- vbi -- Computers can never replace human stupidity. pgpSlYEBvlopx.pgp Description: PGP signature
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 PROTECTED] 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 woody chroot: 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 hit us. 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. 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]
Re: Getting rid of circular dependencies, stage 3
On Wed, Jan 11, 2006 at 11:15:35AM +0100, Josselin Mouette wrote: Le mercredi 11 janvier 2006 à 10:10 +0100, Henning Glawe a écrit : a) explicitely forbid circular dependencies in policy At the very least, I think they should be treated like pre-depends, with a request on this list being mandatory before adding a circular dependency. Until now, all circular dependencies cases I have met were fixable. At first, some of them looked necessary and they required quite some work, but they were fixable. You know when you're adding a pre-depends. You're typing the word Pre-Depends in a debian/control file. You don't know when you're introducing a circular depends that easily, and it could be either of the packages in the circle that shouldn't have such a depends, not necessarily the last one that closed the circle should change. Now, I agree they should be avoided where possible. But I'm afraid that needs to happen by having skilled people having dealt with similar issues before detecting them by running repository-wide dependency analysis on a regular basis, and then advising how to fix it. This happens to be what's happing now, actually. It'd be nice if QA's debcheck could be extended to detect circular dependencies and list them. Let's start by filing a wishlist bug on qa.debian.org for that :). #347676 --Jeroen -- Jeroen van Wolffelaar [EMAIL PROTECTED] (also for Jabber MSN; ICQ: 33944357) http://Jeroen.A-Eskwadraat.nl -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
Bill Allombert wrote: Is it a request I report one ? I will if you want. Shrug, I can ignore useless bug reports and/or orphan packages when things get too annoying with the best of them. (Hmm, didn't I already do that?) 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.. 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? 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. -- see shy jo signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
Joey Hess [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] Joey Hess [EMAIL PROTECTED] 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. Well, I'm not sure if that is an excuse for violating policy. (Actually apt is the one violating policy, but if apt did work as policy states it should these packages [like all other packages with circular dependencies] would be uninstallable, which as debconf is essential, would probably be a critical priority bug.) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Mon, 9 Jan 2006, Bill Allombert wrote: Andreas Tille [EMAIL PROTECTED] wordnet wordnet-base A new version of WordNet was uploaded just yesterday to experimental. It also solves this issue but there is something wrong with the dict-wn: http://lists.debian.org/debian-devel/2006/01/msg00417.html Once this is solved the circular dependency issue will be solved in Etch. Kind regards Andreas. -- http://fam-tille.de -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Mon, Jan 09, 2006 at 07:20:46PM +0100, Bill Allombert wrote: Debian Xfce Maintainers [EMAIL PROTECTED] xfce4-mixer xfce4-mixer-alsa xfce4-mixer-oss Can you remind me why circular dependencies are so terrible? These packages install fine and upgraded fine. What did we miss? -- Simon Huggins \ If at first you don't succeed, you'll get lots of advice. \ http://www.earth.li/~huggie/htag.pl 0.0.22 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
ma, 2006-01-09 kello 21:15 +, Simon Huggins kirjoitti: On Mon, Jan 09, 2006 at 07:20:46PM +0100, Bill Allombert wrote: Debian Xfce Maintainers [EMAIL PROTECTED] xfce4-mixer xfce4-mixer-alsa xfce4-mixer-oss Can you remind me why circular dependencies are so terrible? These packages install fine and upgraded fine. What did we miss? One things, if I've understood things correctly, is that it is not possible to reliably know how they're going to be removed -- dpkg will break the circle in a random place and this may or may not result in problems at the removal stage, depending on what the package does when being removed in various scenarios. Without circular dependencies, things are simpler and easier, since things happen in more deterministic ways. I don't know if that is sufficient reason to get rid of circular dependencies. -- On IRC, we sometimes like to watch silence. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
On Tue, Jan 10, 2006 at 01:17:38AM +0200, Lars Wirzenius wrote: One things, if I've understood things correctly, is that it is not possible to reliably know how they're going to be removed -- dpkg will break the circle in a random place and this may or may not result in the problems occur when apt processes long lists of packages, and more specifically in the 'configure' stage. dpkg has only partly to do with this; the problem is in APT and the way it controls dpkg: due to a limited command line length, apt can only call dpkg with a certain number of packages on the same time. dpkg can handle circular dependencies fine as long as both 'ends' are fed in at the same time. but, at least the last time I checked the apt source, apt doesn't check for this condition when splitting the to-be-configured list and passing these chunks to dpkg. the last hack made by the apt people was to increase the length of these chunks (which decreases the probability of the bugs invokation). well, now people may say: who ever feeds so many packages into apt at the same time? - answer: try an 'apt-get dist-upgrade' from woody to sarge... I don't know if that is sufficient reason to get rid of circular dependencies. well, everything that makes package management tasks _interactive_ is a major showstopper for use in bigger installations (hpc clusters, enterprise desktops). ok. 'nuff ranted. -- c u henning signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
On Tue, Jan 10, 2006 at 12:43:19AM +0100, Henning Glawe wrote: On Tue, Jan 10, 2006 at 01:17:38AM +0200, Lars Wirzenius wrote: One things, if I've understood things correctly, is that it is not possible to reliably know how they're going to be removed -- dpkg will break the circle in a random place and this may or may not result in the problems occur when apt processes long lists of packages, and more specifically in the 'configure' stage. dpkg has only partly to do with this; the problem is in APT and the way it controls dpkg: due to a limited command line length, apt can only call dpkg with a certain number of packages on the same time. dpkg can handle circular dependencies fine as long as both 'ends' are fed in at the same time. but, at least the last time I checked the apt source, apt doesn't check for this condition when splitting the to-be-configured list and passing these chunks to dpkg. Shouldn't apt be fixed rather than changing other packages, then? Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Getting rid of circular dependencies, stage 3
Bill Allombert wrote: Here the lists of packages involved in circular dependencies listed by maintainers. Joey Hess [EMAIL PROTECTED] 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.) 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. -- see shy jo, if it's not broken .. signature.asc Description: Digital signature
Re: Getting rid of circular dependencies, stage 3
On Tue, Jan 10, 2006 at 11:42:49AM +1100, Hamish Moffatt wrote: On Tue, Jan 10, 2006 at 12:43:19AM +0100, Henning Glawe wrote: On Tue, Jan 10, 2006 at 01:17:38AM +0200, Lars Wirzenius wrote: One things, if I've understood things correctly, is that it is not possible to reliably know how they're going to be removed -- dpkg will break the circle in a random place and this may or may not result in the problems occur when apt processes long lists of packages, and more specifically in the 'configure' stage. dpkg has only partly to do with this; the problem is in APT and the way it controls dpkg: due to a limited command line length, apt can only call dpkg with a certain number of packages on the same time. dpkg can handle circular dependencies fine as long as both 'ends' are fed in at the same time. but, at least the last time I checked the apt source, apt doesn't check for this condition when splitting the to-be-configured list and passing these chunks to dpkg. Shouldn't apt be fixed rather than changing other packages, then? What does fixed mean here? The behavior of circular dependencies is undefined in policy, and must be so, because two packages cannot (in this universe) each be configured before the other. If you can solve this problem, then it makes sense to talk about fixing apt instead of fixing the packages, but not before then. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
