Oh gOD....
Humm, just did 'conary erase glibc'.
Although you are probably thinking "What the fuck did he do??? And why?", it has an explanation.
In debian, when I try to do something as stupid as that, debian warns me. I just wanted to check whether conary has that type of safe checking. It has not and now I'm using Foresight for a moment.
I'm going to stick with Foresight for a while, so I'll publish here my experience with it. It is based in rPath, so I don't think it will make a big of a difference. Maybe I'll try 'conary erase conary' LOL ;)
posted by shelika @ 3:44 PM
3 Comments:
On my system, "conary erase glibc" only erases the components of glibc which are not required by other things in the system. In other words, it erased glibc:doc, and nothing else.
[root@localhost msw]# conary erase glibc
Applying update job:
Erase glibc(:doc)=2.3.5-7-0.1
[root@localhost msw]# conary q glibc:lib
glibc:lib 2.3.5-7-0.1
Conary will not let you erase anything that has other dependencies on the system. If you conary q | grep glibc, you'll see that the important bits are still there, :runtime, :lib, :devel, :devellib, though :doc and the super-package is gone.
conary erase conary would in fact remove conary from your system as there are no direct dependencies. There is an interactive mode that you probably want to set by default while learning conary.
Well, my newly installed system just allowed me to do that. The only thing I was left with was an unusable system.
Probably something got broken in the first place, because as you said, that should not happen. I'm very familiar with dependencies because of apt-get, so that's not a big news for me. Humm I'm trying Foresight now, but I'll go back to rPath in a day or two.
Thanks for the feedback though.
Post a Comment
<< Home