I recently wanted to emerge a package (i think it was aumix or something) and got and configure-error. I posted this in the bugzilla and a few minutes later the package was fixed (congratulations!). But the corrected version was from the next release of aumix and this has been unstable. So I emerge the ebuild itself manually. But when doing emerge -u world the next time, portage tried to downgrade aumix. But the old ebuild was broken. I didn't know of the -U option to emerge and so i entered ~i386 as the hostmask in my make.conf to change to an unstable system. A few weeks later i uncommented this line because I thought an unstable system is not what I want. Then at the next emerge -u world gentoo began to downgrade all the unstable packeges. One of them was glibc. After downgrading it, nearly nothing was working at all.... I'm currently reinstalling my whole linux-box. So if you change from unstable back to stable and forget -U one time your gentoo is broken. Reproducible: Always Steps to Reproduce: 1. Switch to an unstable system 2. emerge -u world 3. Switch back to a stable system 4. emerge -u world Actual Results: A lot of applications (I can't remember wich ones but they were a lot as you can imagine) didn't run because they were linked with a more recent version of glibc. Expected Results: There should be a flag for telling portage to NOT downgrade any packages in the make.globals which is set to on. If one wants to downgrad a specific package he could do it manually by emerging the specific ebuild. And power users could overwrite this by a setting in their make.conf. I think it would be more safe especially for not so skilled users as me if downgrading is disabled by default because normaly noone has to downgrade anything. And if one really wants to downgrade something he must be knowing what he is doing and thus he should know how to downgrade a packed manually by emerging the old ebuild.
Also, the whole idea of a global ACCEPT_KEYWORDS does not appeal to me. I rather use alias ex='ACCEPT_KEYWORDS="~x86" ' in /etc/profile and then: ex emerge -U whatever for experimental and emerge -U whatever for "normal" which is in turn connected with the question "why isn't -U default, and -u the special case ?", I am wondering... (ok, it doesnt make much difference if you write -u or -U... though I'd rather like to see a make.conf option for this, as _nobody_ in his right frame of mind should even consider using only "-u" after he ran "-U" once and installed stuff -- it pretty much leaves stuff unusable... already happened to me as well, though only with a small subset, fortunately) Also I'm using http://ifurita.kicks-ass.net/localportage.tar.gz to make portage use a local /usr/local/portage/profiles/package.mask too (it works like this: emerge gets wrapped, the wrapper catches "sync" and after emerge-original did sync, it modifies the /usr/portage/profiles/package.mask according to /usr/local/portage/profiles/package.mask... which is a hack, but it allows me to *add and remove* entries from package.mask "once and for all" as I want my system ;) -- its all a matter of taste, I guess..) (Installation: link it somewhere into PATH *before* the original emerge's path, for example /usr/bin/wrappers -- you have to emerge colorgcc to get this directory up and working) If you are asking for a reason why I do this, I'm reading many of the packages' sources and I mask those which look horrible / have obvious bugs / etc... ;) (can you say "metalog", for example :->)
I think that portage should be improved to remember what masked packages were installed by the user and to treat that version as unmasked on the current system. For instance, if I say something like this: emerge --unmask mozilla-1.3-r1 This would install the masked package and make a note that, on this system, that package is now unmasked. When the package gets unmasked in the official release, this "temporary unmask" note would be removed. This would not interfere with normal ebuilds since they would not get marked as needing a local unmasking, and thus, if an ebuild should ever get remasked, portage would continue to recommend a downgrade of such a package. This unmask note would have to occur at the same level as the cached KEYWORD info and not try to kludge things by tweaking versions in the world file (since that does not work reliably). Currently I kludge around this by having a perl script forcibly unmask a list of packages after every "emerge sync". It does this by directly tweaking the KEYWORDS line in the ebuilds. I'd like something less kludgey for the future, though, especially since signed ebuilds are coming and that will presumably break my kludge method.
package.keywords bug 13616
