On Fri, Jun 08, 2007 at 18:11:01 +0530, arnuld wrote:

now i am sure this is CRUX specific. i am very much hungry on getting an answer to this question as it is revolving in my brain since beginning. I guess the answers to it might have some (historical :-)) value, so I feel inclined to explain.

prt-get is a front-end to pkgutils, the CRUX ports-system, and it handles dependencies automatically while installing packages. i want to know why it does not handle dependencies while remove that specific package which is quite opposite to apt-get. Well 'prt-get install' doesn't install dependencies either, unlike apt-get.

So one first answer to your question is consistency: # prt-get install openbox # prt-get remove openbox Now, assuming that the former installs only openbox and no additional dependencies, if the later would remove openbox plus dependencies that would be inconsistent, and most certainly surprise the user. Also see http://en.wikipedia.org/wiki/Principle_of_least_surprise

i know we have "pkgfoster" available but why that "removal dependency-handling" was not built into prt-get when we have built "installation using dependencies". may be because of KISS approach but myself, being a newbie failed to see a connection. may you explain please ?

So IOW, why is there no 'depremove'... The reason why it's not there so far is that it's somewhat hard to get it right: a. Since there's no meta data in the pkgdb, there's no way to tell the actual dependecies of a package (unless their dynamically linked, in which case ldd magic can be used). The dependencies in the Pkgfile might change, in which case 'remove' could leave stale dependencies around. b. there might be packages depending on others without having it listed as a dependency in the Pkgfile. Using ldd, it should be possible to identify those, but that comes with a major speed penalty (check all installed packages whether they're linked against it) c. Some package may have no dependent packages, but you want to keep them nevertheless. Consider this real world example: the window manager 'openbox' comes with a configuration tool, called 'obconf'. The 'obconf' port from the portdb depends on 'openbox'. Now imagine you've had openbox installed before, and decide to try 'obconf'; after a while you realize you don't like it. 'prt-get remove obconf' as you imagine it would then remove openbox as well, since there are no other packages depending on it on the system. Here, you have to bring in external knowledge about the user's preferences. One of my credos for prt-get has always been "If you can't do it right, don't do it at all", and with that in mind, adding a 'depremove' feature which would potentially do the wrong thing at times seemed a bad idea. Maybe in the future the gain of having it will overweight the costs, however for the time being just keep in mind that it's very easy to do what you want with the existing commands, as pointed out in an earlier thread of yours [1]. Hope this clears it up. Johannes References: 1. http://lists.crux.nu/pipermail/crux/2007-May/007510.html -- Johannes Winkelmann mailto:jw@smts.ch Zurich, Switzerland http://jw.smts.ch