<quote name="Nicholas Blatter" date="Thu, 4 Nov 2010 at 11:47 -0600"> > On Mon, Nov 1, 2010 at 1:36 PM, Bryan Murdock <[email protected]> wrote: > > I just tried those two examples on an Ubuntu 10.04 machine real quick. > > Didn't have any problems either way, FWIW. > > Thanks for checking. > > For the curious, I've found an answer via debian-users: > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=401835 > > It appears order DOES matter when specifying what packages to install > via aptitude and apt-get. This ambiguity is unfortunate (and is > definitely a bug), but apparently solving the problem involves too > much work and as such the bug is wontfix.
Yes, that's just what I thought it would be, and no I don't consider it to be a bug, although it is (on the surface at least) ambiguous and it is unfortunate. But here is what I understand to be going on. In the linked archive message, the poster says "Please note that the xterm is a dependency of xorg that can (and should) be satisfied alternatively" and he is absolutely correct. It *should* be satisfied alternatively. When gnome-desktop-env is listed first, it's dependencies are calculated first, and gnome-terminal is marked for install. Then, when xorgs dependencies are calculated, it looks for an x terminal emulator, which is _already_ satisfied by the marked-for-installation gnome-terminal. Hence, xterm and it's dependent xbitmaps are not marked for install. However, when you reverse the order, xorg looks to satisfy a terminal emulator, and by whatever default satisfaction voodoo goes on, it picks xterm and pulls in xbitmaps. Then it goes on to calculate gnome-desktop-env, which *explicitly* depends on gnome-terminal, so that is still marked for installation regardless. As for your specific case that actually fails on dependencies, I imagine whichever the fail case is, the earlier package pulls in an alternative dependency that otherwise would have been met by the later package, but which also pulls in something that conflicts with a dependency of the later package. In this case it definitely could be considered a bug. The conflicting packages should at that point be examined more closely to find an alternative configuration that does not conflict. In short, if it is possible to install a set of packages without conflict, then that configuration SHOULD be discovered and staged for installation, no matter what order they are specified. -- Von Fugal
pgpUavE195jff.pgp
Description: PGP signature
-------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
