Re: [gentoo-user] Strangeness in dep calculation
On Tuesday 05 July 2011 00:18:48 Roman Zilka did opine thusly: I think this is the root cause of your questions. You say portage has no way to know the difference - who says that is true? Did you assume it? It sure is possible. I assumed what I did because the ebuild of a virtual and a normal package reveal no differences relevant to this, as it seems to me with my level of knowledge. Also, asking for a virtual as a runtime dep is done in the same way as asking for any other package. Furthermore, the manpage for emerge says nothing about the virtuals being different w.r.t. --update or any other option. Let's face it, it's quite a reasonable assumption. If you still want (need?) a proper answer, post a bug at b.g.o. with clear examples and wait for Zac to answer up. I'm tending toward what you see is the intended behaviour, but poorly documented at this point. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Strangeness in dep calculation
On Monday 04 July 2011 14:47:47 Roman Zilka did opine thusly: Hi once again, am I missing something or are these bugs? If bugs, do you think I should file them through bugzilla? # emerge -uDN --with-bdeps y world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. So a routine world update says nothing needs to be done right now. # emerge -uN -D 100 --with-bdeps y world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. I expect this to be the same, it will halt after a depth of 100 (a gigantic depth just btw) # emerge -ep world .. shows mostly remerges, but also 6 new merges, for example sys-devel/autogen and virtual/pam. Shouldn't there be no new merges here? Let's re-check. # equery d virtual/pam * These packages depend on virtual/pam: net-mail/mailbase-1 (pam ? virtual/pam) net-misc/openssh-5.8_p1-r1 (pam ? virtual/pam) sys-apps/openrc-0.8.3-r1 (pam ? virtual/pam) sys-apps/shadow-4.1.4.3 (pam ? virtual/pam) sys-auth/consolekit-0.4.4 (pam ? virtual/pam) x11-apps/xdm-1.1.10-r1 (pam ? virtual/pam) x11-misc/xlockmore-5.31 (pam ? virtual/pam) -ep is not the same as -avuND! The former is what happens if you tell portage to consider nothing to be merged yet. It will try and rebuild every possible thing you might ever need considering your setup. The latter is simply everything that needs to be done now. With that, build deps and virtuals can be omitted as they do not need to be rebuilt to satisfy the current emerge. Make sense? # emerge -pq virtual/pam [ebuild N] virtual/pam-0 # emerge -uDN --with-bdeps y --autounmask y world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. # grep skype /var/lib/portage/world net-im/skype # emerge -p --autounmask y skype These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ~] net-im/skype-2.2.0.35-r1 [2.1.0.81] USE=-hardened% The following keyword changes are necessary to proceed: #required by skype (argument) =net-im/skype-2.2.0.35-r1 ~amd64 NOTE: This --autounmask behavior can be disabled by setting EMERGE_DEFAULT_OPTS=--autounmask=n in make.conf. # grep KEYWORDS /usr/portage/net-im/skype/skype-2.* /usr/portage/net-im/skype/skype-2.1.0.81.ebuild:KEYWORDS=~amd64 ~x86 /usr/portage/net-im/skype/skype-2.2.0.25.ebuild:KEYWORDS=~amd64 ~x86 /usr/portage/net-im/skype/skype-2.2.0.35-r1.ebuild:KEYWORDS=~amd64 ~x86 .. Shouldn't 'emerge -uDN world' pull in skype-2.2.0.35-r1 too, as per the autounmask functionality? autounmask is not the same as autounmask-write, and neither means to automatically install the absolute latest version in the tree. The former will tell you what you need to do to satisfy deps, and the current stable skype might suit. You haven't unmasked skype and portage does not need to unmask anything to satisfy a world update. So it is quite happy leaving things as they are. If you want latest skype, you have two approaches: Keyword it manually, Run an unstable system. Portage will not all of it's own do anything to violate you ACCEPT_KEYWORDS setting - that one trumps everything when automation kicks in. In short, portage is working as designed and your understanding is faulty. I'm using latest stable portage for this - 2.1.10.3. ~arch is 2.1.10.4 and I haven't tried it, but its changelog doesn't suggest any changes in relevant areas. # cat /etc/portage/package.keywords =sys-boot/grub-1.97.1 ** =app-emulation/wine-1.3.15 ~amd64 # cat /etc/portage/package.mask sys-boot/grub-1.0 # cat /etc/portage/package.use media-libs/libsdl joystick dev-python/PyQt4 webkit dev-libs/libxml2 python dev-lang/perl ithreads media-plugins/audacious-plugins scrobbler # emerge --info Portage 2.1.10.3 (default/linux/amd64/10.0/desktop, gcc-4.4.5, glibc-2.12.2-r0, 2.6.38-gentoo-r6 x86_64) = System uname: Linux-2.6.38-gentoo-r6-x86_64-AMD_Athlon-tm-_X2_Dual-Core_QL-65-wit h-gentoo-2.0.2 Timestamp of tree: Sun, 03 Jul 2011 18:15:01 + app-shells/bash: 4.1_p9 dev-lang/python: 2.7.1-r1, 3.1.3-r1 dev-util/cmake: 2.8.4-r1 dev-util/pkgconfig: 0.25-r2 sys-apps/baselayout: 2.0.2 sys-apps/openrc: 0.8.3-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.68 sys-devel/automake: 1.9.6-r3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc:4.4.5 sys-devel/gcc-config: 1.4.1-r1 sys-devel/libtool:2.2.10 sys-devel/make:
Re: [gentoo-user] Strangeness in dep calculation
Alan McKinnon (Mon, 04 Jul 2011 18:24:54 +0200): On Monday 04 July 2011 14:47:47 Roman Zilka did opine thusly: Hi once again, am I missing something or are these bugs? If bugs, do you think I should file them through bugzilla? # emerge -uDN --with-bdeps y world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. So a routine world update says nothing needs to be done right now. # emerge -uN -D 100 --with-bdeps y world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. I expect this to be the same, it will halt after a depth of 100 (a gigantic depth just btw) # emerge -ep world .. shows mostly remerges, but also 6 new merges, for example sys-devel/autogen and virtual/pam. Shouldn't there be no new merges here? Let's re-check. # equery d virtual/pam * These packages depend on virtual/pam: net-mail/mailbase-1 (pam ? virtual/pam) net-misc/openssh-5.8_p1-r1 (pam ? virtual/pam) sys-apps/openrc-0.8.3-r1 (pam ? virtual/pam) sys-apps/shadow-4.1.4.3 (pam ? virtual/pam) sys-auth/consolekit-0.4.4 (pam ? virtual/pam) x11-apps/xdm-1.1.10-r1 (pam ? virtual/pam) x11-misc/xlockmore-5.31 (pam ? virtual/pam) # emerge -pq virtual/pam [ebuild N] virtual/pam-0 -ep is not the same as -avuND! The former is what happens if you tell portage to consider nothing to be merged yet. It will try and rebuild every possible thing you might ever need considering your setup. The latter is simply everything that needs to be done now. With that, build deps and virtuals can be omitted as they do not need to be rebuilt to satisfy the current emerge. Make sense? 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). But it's neither in my world file, nor in my system set (checked with 'emerge -epO system'). So it must be a dependency. Then why doesn't '-uDN --with-bdeps y world' demand it? Obviously, virtual/pam is listed as necessary for running or building something in my world set. '-uDN world' shouldn't omit merging something I need to run my packages. And with '--with-bdeps y' it also shouldn't omit merging something I might ever need to build these packages. The quoted equery call shows that virtual/pam is needed to run 7 pieces of software in my world. (I understand it's not literally needed for them to run, but that's the semantics of runtime deps and portage has no way to know the difference, I suppose.) And it's not an alternative to another possible dependency - it must be virtual/pam (checked some of the ebuilds). Even if it's all correct behavior, I'd still like to know where exactly is the robber on my train of thoughts. # emerge -uDN --with-bdeps y --autounmask y world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. # grep skype /var/lib/portage/world net-im/skype # emerge -p --autounmask y skype These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ~] net-im/skype-2.2.0.35-r1 [2.1.0.81] USE=-hardened% The following keyword changes are necessary to proceed: #required by skype (argument) =net-im/skype-2.2.0.35-r1 ~amd64 NOTE: This --autounmask behavior can be disabled by setting EMERGE_DEFAULT_OPTS=--autounmask=n in make.conf. # grep KEYWORDS /usr/portage/net-im/skype/skype-2.* /usr/portage/net-im/skype/skype-2.1.0.81.ebuild:KEYWORDS=~amd64 ~x86 /usr/portage/net-im/skype/skype-2.2.0.25.ebuild:KEYWORDS=~amd64 ~x86 /usr/portage/net-im/skype/skype-2.2.0.35-r1.ebuild:KEYWORDS=~amd64 ~x86 .. Shouldn't 'emerge -uDN world' pull in skype-2.2.0.35-r1 too, as per the autounmask functionality? autounmask is not the same as autounmask-write, and neither means to automatically install the absolute latest version in the tree. The former will tell you what you need to do to satisfy deps, and the current stable skype might suit. You haven't unmasked skype and portage does not need to unmask anything to satisfy a world update. So it is quite happy leaving things as they are. If you want latest skype, you have two approaches: Keyword it manually, Run an unstable system. Portage will not all of it's own do anything to violate you ACCEPT_KEYWORDS setting - that one trumps everything when automation kicks in. In short, portage is working as designed and your understanding is
Re: [gentoo-user] Strangeness in dep calculation
On Monday 04 July 2011 22:48:44 Roman Zilka did opine thusly: Alan McKinnon (Mon, 04 Jul 2011 18:24:54 +0200): On Monday 04 July 2011 14:47:47 Roman Zilka did opine thusly: Hi once again, am I missing something or are these bugs? If bugs, do you think I should file them through bugzilla? # emerge -uDN --with-bdeps y world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. So a routine world update says nothing needs to be done right now. # emerge -uN -D 100 --with-bdeps y world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. I expect this to be the same, it will halt after a depth of 100 (a gigantic depth just btw) # emerge -ep world .. shows mostly remerges, but also 6 new merges, for example sys-devel/autogen and virtual/pam. Shouldn't there be no new merges here? Let's re-check. # equery d virtual/pam * These packages depend on virtual/pam: net-mail/mailbase-1 (pam ? virtual/pam) net-misc/openssh-5.8_p1-r1 (pam ? virtual/pam) sys-apps/openrc-0.8.3-r1 (pam ? virtual/pam) sys-apps/shadow-4.1.4.3 (pam ? virtual/pam) sys-auth/consolekit-0.4.4 (pam ? virtual/pam) x11-apps/xdm-1.1.10-r1 (pam ? virtual/pam) x11-misc/xlockmore-5.31 (pam ? virtual/pam) # emerge -pq virtual/pam [ebuild N] virtual/pam-0 -ep is not the same as -avuND! The former is what happens if you tell portage to consider nothing to be merged yet. It will try and rebuild every possible thing you might ever need considering your setup. The latter is simply everything that needs to be done now. With that, build deps and virtuals can be omitted as they do not need to be rebuilt to satisfy the current emerge. Make sense? 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). But it's neither in my world file, nor in my system set (checked with 'emerge -epO system'). So it must be a dependency. Then why doesn't '-uDN --with-bdeps y world' demand it? Obviously, virtual/pam is listed as necessary for running or building something in my world set. '-uDN world' shouldn't omit merging something I need to run my packages. And with '--with-bdeps y' it also shouldn't omit merging something I might ever need to build these packages. The quoted equery call shows that virtual/pam is needed to run 7 pieces of software in my world. (I understand it's not literally needed for them to run, but that's the semantics of runtime deps and portage has no way to know the difference, I suppose.) And it's not an alternative to another possible dependency - it must be virtual/pam (checked some of the ebuilds). I think this is the root cause of your questions. You say portage has no way to know the difference - who says that is true? Did you assume it? Why should virtual packages behave like regular packages? They are even in a different category to everything else. Treating virtuals just like regular packages doesn't make sense to me. Treating them as variables does make sense - they get expanded into lists of possibilities and when the graph is resolved, the existence of the virtual goes away. But that is speculation on my part. I think if you get an authoritative answer to that question, then we can continue to examine the behaviour. Otherwise we are just guessing. Even if it's all correct behavior, I'd still like to know where exactly is the robber on my train of thoughts. # emerge -uDN --with-bdeps y --autounmask y world Calculating dependencies... done! Auto-cleaning packages... No outdated packages were found on your system. # grep skype /var/lib/portage/world net-im/skype # emerge -p --autounmask y skype These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild U ~] net-im/skype-2.2.0.35-r1 [2.1.0.81] USE=-hardened% The following keyword changes are necessary to proceed: #required by skype (argument) =net-im/skype-2.2.0.35-r1 ~amd64 NOTE: This --autounmask behavior can be disabled by setting EMERGE_DEFAULT_OPTS=--autounmask=n in make.conf. # grep KEYWORDS /usr/portage/net-im/skype/skype-2.* /usr/portage/net-im/skype/skype-2.1.0.81.ebuild:KEYWORDS=~a md64 ~x86 /usr/portage/net-im/skype/skype-2.2.0.25.ebuild:KEYWORDS=~a md64 ~x86
Re: [gentoo-user] Strangeness in dep calculation
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. -- Neil Bothwick I'm not opinionated, I'm just always right! signature.asc Description: PGP signature
Re: [gentoo-user] Strangeness in dep calculation
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. -rz
Re: [gentoo-user] Strangeness in dep calculation
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? -rz
Re: [gentoo-user] Strangeness in dep calculation
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). But it's neither in my world file, nor in my system set (checked with 'emerge -epO system'). So it must be a dependency. Then why doesn't '-uDN --with-bdeps y world' demand it? Obviously, virtual/pam is listed as necessary for running or building something in my world set. '-uDN world' shouldn't omit merging something I need to run my packages. And with '--with-bdeps y' it also shouldn't omit merging something I might ever need to build these packages. The quoted equery call shows that virtual/pam is needed to run 7 pieces of software in my world. (I understand it's not literally needed for them to run, but that's the semantics of runtime deps and portage has no way to know the difference, I suppose.) And it's not an alternative to another possible dependency - it must be virtual/pam (checked some of the ebuilds). I think this is the root cause of your questions. You say portage has no way to know the difference - who says that is true? Did you assume it? It sure is possible. I assumed what I did because the ebuild of a virtual and a normal package reveal no differences relevant to this, as it seems to me with my level of knowledge. Also, asking for a virtual as a runtime dep is done in the same way as asking for any other package. Furthermore, the manpage for emerge says nothing about the virtuals being different w.r.t. --update or any other option. Why should virtual packages behave like regular packages? They are even in a different category to everything else. Treating virtuals just like regular packages doesn't make sense to me. Treating them as variables does make sense - they get expanded into lists of possibilities and when the graph is resolved, the existence of the virtual goes away. But that is speculation on my part. Why do we have so many virtuals installed then? But yeah, who knows... I think if you get an authoritative answer to that question, then we can continue to examine the behaviour. Otherwise we are just guessing. It seems that you assume that my current skype is a stable version. In fact, it isn't - see the quoted grep of the ebuilds. There is not a single stable version of skype in portage now. They're all ~arch. My ACCEPT_KEYWORDS=amd64. 'emerge skype' (I'll be omitting the '--autounmask y', it's the default anyway) wants to upgrade from my current 2.1.0.81 ~skype to 2.2.0.35-r1, which happens to be the latest available ~skype. I assume that's the strategy: if there's no stable version available, at least get the latest ~arch version. That's fine. But why doesn't the same strategy apply for a '-uDN world'? The manpage says nothing about this, as my eyes interepret it. There might be some unintended hidden behavior of --autounmask or --update or something else. If it's intended, I'd still like to understand the reasoning - just to get what's going on. You'd have to ask Zac what he intended. I can easily see the code being written such that emerging a package and updating world use completely different code paths, simply because they must evaluate things differently with subtle differences. You'd really have to read the code to get proper answers to your questions. As we say in the eXtreme Programming world: The code IS the design. Well, I'm not going into the code. Do you think it's meaningful to either bring these two issues into attention of Zac directly, or file official bugs? I've never done either and lack experience on determining when is the right time.:) Neither of the two issues cause any visible harm in the system as a whole - it's not like I'm not sleeping because of them. I stumbled upon them by mere chance. I'm just trying to reveal a possible bug or two. -rz
Re: [gentoo-user] Strangeness in dep calculation
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
Re: [gentoo-user] Strangeness in dep calculation
Henry Gebhardt (Tue, 5 Jul 2011 00:21:22 +0200): 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/. I was expecting to find this to be the cause, because I absolutely didn't think of it and it sounds likely. But /var/db/pkg/net-misc/openssh-5.8_p1-r1/RDEPEND requires virtual/pam too. -rz
Re: [gentoo-user] Strangeness in dep calculation
Roman Zilka (Tue, 5 Jul 2011 00:36:21 +0200): Henry Gebhardt (Tue, 5 Jul 2011 00:21:22 +0200): 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/. I was expecting to find this to be the cause, because I absolutely didn't think of it and it sounds likely. But /var/db/pkg/net-misc/openssh-5.8_p1-r1/RDEPEND requires virtual/pam too. Furthermore, FWIW, I tried the following. # USE=-pam emerge -v1 openssh // indicated the change in the pam USE flag and rebuilt openssh # emerge -pv openssh [ebuild R] net-misc/openssh-5.8_p1-r1 USE=X hpn ldap pam* -X509 -kerberos -libedit (-selinux) -skey -static -tcpd 0 kB # emerge -vuD --changed-use --with-bdeps y world [ebuild R] net-misc/openssh-5.8_p1-r1 USE=X hpn ldap pam* -X509 -kerberos -libedit (-selinux) -skey -static -tcpd 0 kB No signs of virtual/pam. -rz
