When one does an 'emerge --update --deep world', the entire dependency tree of all currently installed applications is checked and updated if necessary. However, this causes problems if the USE flags have changed since certain packages have been installed. For example, I installed media-video/mplayer-1.0_pre3 with "-arts" in my USE flags. If I add "arts" to my USE flags, see what happens: # env USE="arts" emerge -upvD world These are the packages that I would merge, in order: Calculating world dependencies ...done! [ebuild N ] x11-libs/qt-3.2.3-r1 +cups -doc +gif -mysql +nas -odbc +opengl -postgres 13,625 kB [ebuild N ] kde-base/kde-env-3-r2 [empty/missing/bad digest] [ebuild N ] kde-base/arts-1.1.5 -alsa -artswrappersuid +mad +oggvorbis 966 kB Total size of downloads: 14,591 kB OVERLAY: *1:/usr/local/portage Note that mplayer was not rebuilt. This means that qt, kde-env, and arts will be installed for mplayer, but never used, since it is necessary to rebuild it to include the new output method. The same problem can be seen with net-im/gaim, which requires dev-libs/nspr and dev-libs/nss when compiled without the 'mozilla' flag. There are two possible solutions to this: 1. Detect when this problem arises, and re-merge the package. I'm not sure this is at all easy to do, though. It would need to be quite clever to stop re-merging packages unnecessarily. 2. Check the USE flags that each package was installed with, and use those flags when examining dependencies. So, if mplayer was installed without the 'arts' flag, it won't use arts until it is explicitly re-merged (i.e. world or dependency updates won't use arts, but an explicit re-merge will). This latter solution might actually be a desirable feature of portage even aside from this bug. Perhaps this should be a different report, but if I specify that I want a package installed with certain USE flags: $ env USE="foo -bar baz" emerge abc Then it makes sense to keep those USE flags when that package is updated, etc. I'm not sure whether this should apply to all USE flags. If I decide suddenly that IPv6 interests me, and I add "ipv6" to my USE flags, then it makes sense to add ipv6 support to all future packages that have it, whether or not they had it when I first installed them. This sort of mechanism would require (a) knowing the difference between make.conf USE flags and environment USE flags, and (b) storing them separately to /var/db/pkg/category/pkgname/USE. Perhaps (a) could be solved by having a separate mechanism for "locking" USE flags, but this is now getting very complicated. Regardless of this ability to lock USE flags, there is definitely a problem with portage installing dependencies without rebuilding the package.
*** This bug has been marked as a duplicate of 16156 ***
This bug is not a "duplicate" of bug 16156. This bug highlights an important problem to do with USE flags, namely, how to deal with USE flags that change over time. The Request for Enhancement in bug 16156 would be one possible solution to this bug, although by no means the only one. As such, 16156 is maybe a subset of this bug. I would move my discussion to bug 16156, but it is barely relevant. The two bugs are similar, but my discussion is about a much more general view of USE flags, not just one feature request. Another example of why this bug is a big problem (which should not be marked as "resolved, duplicate" and ignored from then on) can be seen with 'emerge depclean'. When portage does a 'depclean', it removes all packages installed that are not depended on (to any depth) by packages listed in the world file. However, when it examines the packages in the world file, it treats them as being installed with the CURRENT USE flags. For example: I install xmms with "+arts". Thus, kde-base/arts gets compiled and installed on my system. I now remove "arts" from my USE flags, and do an 'emerge depclean'. Portage will see that xmms only depends on kde-base/arts if the "arts" USE flag is set, and it will further see that the "arts" USE flag is NOT set any more. It will thus try to remove kde-base/arts from my system. However, the installation of xmms that I currently have on my system has kde-base/arts as a runtime dependency, and since it has not been recompiled with the new USE flags, it will break when it is run. I cannot actually think of any solution to this problem that is easy to implement, or to use. My USE flags should represent the way my system currently works, so all packages should be recompiled to reflect the new USE flags, when I change them. But, at the same time, sometimes I want to specify other USE flags (so, only java and python get compiled with documentation ("+doc"), and not db, or qt, or anything). Thus there has to be a new distinction in USE flags - those explicitly asked for, for a package, and those which are simply "the way the system runs".
This bug is a bug, not a feature request - it highlights a problem with the way Portage handles USE flags for a specific application. Deeper thought needs to be put into what we want portage to do in situations like this, and how we want special cases to be handled. Bug 16156 is a possible solution - there are others.
--newuse should provide this functionality...
