Sorry about the long bug report, I felt I had to explain a lot of things since this issue apparently hasn't been brought up yet. This is somewhere halfway between a bug and a missing feature, as it's probably meant to be this way but the end result is very confusing and potentially dangerous security-wise. Joe User will typically emerge several key features after the initial install, not by emerging a hundred packages one by one, but by picking "top level" packages such as kde and php. These autoemerge tens if not hundreds of other packages due to the dependency tree. The specifically emerged packages then go in the world-file and will be kept up to date by doing 'emerge --update world'. This is how the majority of users keep their system up to date in terms of packages and everyone seems to think that when doing so, their system is in perfect shape with all the latest stuff. And so did I, until recently. Then I noticed a new ebuild for Apache being rsync'ed, but even though I had Apache installed nothing happened on 'emerge --update world'. And no trace of a block in package.mask either. This made me curious, since I very much wanted this new Apache-version due to the exploits available for the old one. A short investigation showed that I had emerged php directly, which in turn autoemerged apache (and about fifty other packages) for me. Therefore, no sign of apache in my world-file and to make sure I'm up to date I have to explicitly 'emerge --update apache'. So I wrote a small script to compare what I had installed to what's available, and on a typical box I found this list: aragorn ok # ./gencheck app-crypt/mhash : 0.8.9 < 0.8.16 dev-db/mysql : 3.23.49-r1 < 3.23.49-r2 dev-libs/glib : 2.0.3 < 2.0.4 dev-libs/libmcrypt : 2.4.19-r1 < 2.5.1-r1 media-gfx/sane-backends : 1.0.7-r1 < 1.0.8 media-libs/gdk-pixbuf : 0.17.0 < 0.18.0 media-sound/xmms : 1.2.7-r9 < 1.2.7-r8 net-libs/libwww : 5.3.2-r1 < 5.4.0 net-print/cups : 1.1.14-r4 < 1.1.15 sys-apps/console-tools : 1.06-r1 < 0.2.3-r4 sys-apps/pam-login : 3.6-r1 < 3.6-r2 sys-apps/texinfo : 2.95.3-r5 < 4.2-r2 x11-libs/gtk+ : 2.0.3 < 2.0.5 x11-libs/pango : 1.0.2 < 1.0.3 x11-libs/qt : 3.0.4.1-r1 < 3.0.4.20020606-r1 On my box, there are 240 emerged packages, of which only 49 are mentioned in the world-file. Some of the difference may be automatically kept up to date since they're considered "system", but the rest will hardly ever be updated unless you either do it by hand or some package that depends on them is installed/updated. This makes the dependency system a lot less useful, since you can never know what state a system is in without emerging every package by hand or going through the world-file and trying to remember which packages should have been there. 'emerge --update world' is therefore reduced to something that simply updates a more or less random number of packages on a system, and there is no easy way of determining which ones it missed out. Quite a few security holes are fixed by updating particular libraries, and not the actual product. And in the case of the Apache vulnerability, having emerged php directly will leave you vulnerable even though the new apache ebuild is available. Your average Gentoo-user will be vulnerable to such problems much longer than needed. Won't fix the statically linked problems of course, but you can't have everything. So, the proposition is: 1. Think of a better way of making sure ALL emerged packages are kept up to date, possibly by renaming the option "world" to "bermuda_triangle" and create a new "world" thing that actually updates everything you have installed. :-) Or think up a third name, e.g. "all" that will update every package on your machine to the latest available. I'm sure there are some dependency problems that might have to be worked out to get this going, but it certainly should be fixed.I expect at least one command that will make sure my whole system is up to date, _without_ having to resort to --emptytree. 2. As a temporary fix, tell people about it and add a new feature to emerge that will allow you to easily see which of your installed packages have newer versions available. So that people can check for themselves, and possibly emerge by hand if needed. Right now the easiest way to do this is with something like: #!/usr/bin/perl # # This script will show outdated packages until someone # changes the "emerge search" output, feel free to use. # open(IN, 'emerge search ".*"|') or die "Can't do emerge search: $!\n"; while(<IN>) { if ( /^.*\*(.*)$/) { $app = $1; } elsif ( /Available: (.*)$/) { $av = $1; } elsif ( /Installed: (.*)$/ ) { $in = $1; if (($in ne "[ Not Installed ]") && ($in ne $av)) { printf("%-40s : %-15s < %-15s\n",$app, $in, $av); } } } close IN; Should of course be rewritten to use the API, not depend on output from emerge...
If php is in your world file and a new release of apache comes out, then an "emerge -u world" should be pulling in the new apache release, provided that it satisfies the apache dependency in the php ebuild. So if apache is not being upgraded, I am not sure why. If you can replicate this behavior I'd be happy to ssh into your box to figure out what is going on.
This bug is fixed in Portage 2.0.6+. (coming soon) :)
