emerge complained it was blocked due to: [blocks B ] <dev-python/pygtk-2.9 (is blocking dev-python/pygobject-2.12.3) assuming emerge was smart enought not do ask to remove a needed package I unmerge =python-2.4*. The warnings recieved are the same as for any package - hense they got ingnored. emerge should require a specific switch to remove a package that will break it... Now the question is how do I recover?
No, user needs to use brain. PEBKAC is not a bug.
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?full=1#blocked
This a MAJOR usability bug Note this also breaks azeurus - no torrent downloads possible here.
# emerge -Cav python >>> These are the packages that would be unmerged: !!! 'dev-lang/python' is part of your system profile. !!! Unmerging it may be damaging to your system. NOT a bug.
We get warnings like this all the time. If this is a more sever message than usual it needs to do more. eg. stop and ASK are you sure. Using a 10 second timer is very lame and error prone.
OK, you didn't read the docs, you said Yes when portage asked you whether you want to unmerge part of your system which can damage it. Can't do much worse than you did, can you? So, kindly stop reopening this bug and go read basic docs, like the handbook.
Closed case; if you insist on reopening this, it will be referred to user relations to handle this. Spent enough time here. There won't be anything changed in portage to prevent users doing really stupid things without doing any research and without thinking.
Yes I read the docs a year ago when I installed... Think of it this way. Any error that is basicly going to force someone to reinstall is bad - they may well choose to install another dist. Preventing this type of error is not hard. So why not accept that this _IS_ a bug? Fixing it helps to keep users on your dist which is a real good thing. Please do refer it to user relations. This may not be a technical bug per say but it _IS_ a bug and this type of error should be hard to make. I speak with about 30 years experience on the system side of computing.
Note that I do consider this important enought to be late for work...
userrel, please deal with this bugspam. Thanks.
From my point of view, I entered a command that was not wise (thats what happens when you work before your first coffee). With one ten second warning that looks the same as the normal 10 second warning, emerge proceeded to commit bork itself. To protect other users I reported this as a bug... Your techical person does not see anything wrong. From a user relations POV his reponse is just plain lame. Thanks Ed Tomlinson <edt@aei.ca> <edward . tomlinson at aero . bombardier . com> cell fiveonefourdashfourninesevendashthreefivesixtwo
Hi Ed, The emerge program itself has no idea what packages will break it (I can think of a few that can off of the top of my head, but they aren't all in DEPEND). The warning you see there is from python being in 'system' and if you remove 'system' packages that warning is printed (not just for python, but for any package in system; python is not extra special here). I think coming up with a list of 'packages that if unmerged can break portage' is a bit unrealistic, that list would perhaps be quite large (I can think of about 10 or so off of the top of my head). I believe the misunderstanding here is that you were trying to solve a block and unmerged python *without knowing that unmerging python would break portage*, am I correct in that assumption? If you can suggest an improvement to the 'you are about to unmerge something in system' message I'd love to make it more informative. However in the future I'd suggest using the '--ask' or '-a' options so that emerge will give you time to double check what it is really doing. Unmerging system packages is never a good idea unless you are *really sure* you know what you are doing. The functionality is there in cases of say, embedded systems such as our liveCD. Once the CD is mastered they need to strip out packages to save space. Thus the functionality needs to exist. If you have any other specific suggestions on how to improve this use case those would also be appreciated. Also a note, if you get 'warnings like that all the time' as you stated in comment #5 I have to wonder how you are triggering them (do you unmerge system packages that often?) Perhaps they are being triggered erronously? Thanks, -Alec Warner Gentoo User Relations Gentoo Portage Developer
I think this bug is perfectly valid. Here's a horrendously bad analogy: Even gunslingers in the Wild West had trigger-guards on their pistols, to prevent them from shooting themselves in the foot after a few beers. As a Linux example, nvclock has "--force" for experimental/dangerous choices. Portage could have "--unsafe", for when it is asked to do most-probably stupid things like remove the only version of python installed. It is not necessary to do a full analysis of the impact of 10,000+ ebuilds before judging whether this is an obviously useful safeguard. Including 10 obvious packages for this feature is far better than considering the feature invalid. I'm seeing the kind of thinking that prevents "rm -r /" from having such a safeguard. There are other such examples of 1970s thinking in the "Unix Haters' Handbook" ;)
This is being looked into. It remains to be seen if it does get fixed but ideas are being thrown around. Aside from the intial pain of getting the bug accepted the help (my system is repaired) and consideration of fixing for this has been nice to see. It can be done much better - try removing a critical package with debian's apt, it lists all packages that need to be uninstalled with the critical ones listed near the end. It tells you that what you are doing is probably stupid and makes you type a phrase to continue. Paul's idea of an --I_am_sure_I_want_to_do_this switch is, in my opinion, a good one. One problem with emulating the debian menthod is that emerge, once started, is suposed to remain noninteractive. There are some ideas on how this might be changed if non running in a script, but this idea is good too.
It looks block that orginated this problem was due to dependencies from the sunrise overlay. [I] media-tv/democracy [1] [1] /usr/portage/local/layman/sunrise
(In reply to comment #13) > I'm seeing the kind of thinking that prevents "rm -r /" from having such a > safeguard. There are other such examples of 1970s thinking in the "Unix Haters' > Handbook" ;) rm -rf / is stupid, anyone who does something that stupid shouldn't be allowed to go near a computer, just as surely as emerge -C python is stupid and anyone who does something that stupid shouldn't be allowed to go near gentoo. rm is the command to remove a file -r deletes files and folders recursively -f forces deletions / is the root partition where everything resides thus deleting everything in / is obviously and logically a really really.. really realy stupid idea. and: portage is the package manager for gentoo python is a script interpreter portage is mostly written in python thus unmerging python is almost as exceptionally stupid as the above example. Just use some common sense, read docs and heed warnings. Believe it or not, but some people want emerge to just work at what you want it to without asking stupid questions. Bugs like this is like complaining about a hammer not working because you're beating the nail (and your hand) with the hook end.
(In reply to comment #5) > We get warnings like this all the time. If this is a more sever message than > usual it needs to do more. eg. stop and ASK are you sure. Using a 10 second > timer is very lame and error prone. > You unmerge _system_ packages _all_ the time? Let us compare the warnings one gets, when they unmerge a package. Suppose I decided I wanted to unmerge Firefox... I'd get this (Note, I use -p here, since I don't /actually/ want to unmerge the package): beast tmp # emerge --unmerge -p mozilla-firefox >>> These are the packages that would be unmerged: www-client/mozilla-firefox selected: 2.0 protected: none omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. No big warnings... no yelling and screaming. If it weren't for -p, it'd go ahead and do it. Now, compare with the message I get if I try and unmerge bash. beast tmp # emerge --unmerge -p bash >>> These are the packages that would be unmerged: !!! 'app-shells/bash' is part of your system profile. !!! Unmerging it may be damaging to your system. app-shells/bash selected: 3.1_p17 protected: none omitted: none >>> 'Selected' packages are slated for removal. >>> 'Protected' and 'omitted' packages will not be removed. See anything different? You should. The text is brightly coloured for that exact purpose. Note it waits longer before unmerging too? 10 seconds instead of the usual 5? Common sense should tell you this is not normal behaviour. The lessons here are: (1) Read what the system tells you -- *especially when unmerging* (2) Think before you do We do our best to make the system as foolproof as possible, but we expect users to exercise the grey matter when using it.
(In reply to comment #17) > We do our best to make the system as foolproof as possible, but we expect users > to exercise the grey matter when using it. Apparently it's too much exercise; some users like to remain couch-potatoes in that respect. I can say this, that if it was a docs bug, like "you didn't warn me emerge -C is bad" (patently false), which is what the reporter is saying, it'd be reso invalid right away.
Please use the --ask functionality in the future. You may add --ask to EMERGE_DEFAULT_OPTS in make.conf so specifying -a every time is not required. I don't see a feasable technical means to accomplish anything better than the current warning (regarding packages in system) and no new warning text was suggested. -Alec
