On Mon, Jul 04, 2011 at 11:59:23PM +0200, Roman Zilka wrote: > Roman Zilka (Mon, 4 Jul 2011 23:34:01 +0200): > > Neil Bothwick (Mon, 4 Jul 2011 22:16:18 +0100): > > > On Mon, 4 Jul 2011 22:48:44 +0200, Roman Zilka wrote: > > > > > > > Not quite. This is how I'm thinking: if '-ep world' says virtual/pam > > > > needs to be installed, then it either > > > > * is in the world file, or > > > > * is in the system set, or > > > > * is a buildtime or runtime dependency (immediate or deep) of one of the > > > > packages in the world set (i.e., world file and system set combined). > > > > > > There's another possibility, that it is one of a number of packages that > > > satisfy a particular dependency, the first listed one. If you have > > > another package installed that fulfils this dependency, emerge -u world > > > won't need to do anything, but with emerge -e world you are telling > > > portage that the other package is not installed, so it picks the first > > > dependency from the list. > > > > I checked that - in this case, there are no alternatives. > > Ah, I see. I'm sorry, I wasn't thinking enough. Yeah, virtual/pam may > be one of a list. But if nothing else, I have openssh and openssh says: > RDEPEND="pam? ( virtual/pam ) > No alternatives there. And I don't have virtual/pam, but do have > openssh. So why does '-uDN world' not pull virtual/pam in?
My guess is that when virtual/pam was introduced, the openssh ebuild was changed to depend on it without a rev bump. Then while upgrading emerge will use the old ebuild of the installed openssh, and when you use --emptytree it will use the new one in the portage tree. You can test the theory by comparing the ebuild in portage with the one in /var/db/pkg/net-misc/. Henry
