>> From pre11 on I often get errors which always look like (this is with >> the last one released, pre17): >> >> # emerge mozilla -p >> >> >> Invalid package name: moznomail >> >> These are the packages that I would merge, in order: >> >> Calculating dependencies >> !!! Problem in net-www/mozilla dependencies. >> !!! 73 >http://bugs.gentoo.org/show_bug.cgi?id=57212 Oh ****, this time you were already into it. As I said, I had similar problems with some 2.0.49 versions already, and back them I didn't find anybody else facing them. I should have checked bugzilla anyway, sorry. >The _pre11 patch you provided will cause lots of problems with regards to >virtuals. For example, if the default virtual/x11 is xfree and the user tries >to emerge xorg-x11, portage will try to install both xfree and xorg-x11 >without those lines. As I explained, it was not itself a patch, but only a hunk of difference between pre10 and pre11 which made pre10 fail when applied. I have no idea of Python, hence I thought the quickest way to find a workaround --which could also be a hint for where to look for a proper bug fix-- was going over every difference between both portage releases. >The _pre17 patch I'm not to sure about, but it is definately unrelated to the >problem you are having - even if enabling the code does appear to fix it. The procedure I followed to get to it was the same as for the pre11. Anyhow, I began to see that it was not a proper fix when I started to read pym/portage.py and bin/emerge more closely, and also after I saw packages and virtuals blocking was not working at all. >Anyway, it is fixed now and will be in portage-2.0.51_pre18. Thanks a lot, I've tried the patch you provide on bug #57212 and it definitely solves all my problems and without any side effect. Virtuals' blocking, packages blocking within normal ebuilds, ... everything works fine. I'll be trying to see if I get again the 'invalid package name' when doing an 'ebuild xxxxxxx.ebuild qmerge' after it has been compiled & installed properly. Since your patch only targets bin/emerge, the ebuild problem will remain. It is much less common to hit a package which shows this behavior, though, at least with pre17, for other older versions it was much more common. BTW, do you think I should file a bug report about the hardened-gcc not existing anymore but being present on current gcc ebuilds? Thanks again :) This indeed was faaast, much faster than my tonight chasing session (in a language unknown to me). -- "Our nation must come together to unite." George W. Bush June 4, 2001 Remark made in Tampa, Florida. Javier Marcet