Or in Cave FAQ. While on the topic of "install" vs. "resolve", is there any advantage to "cave uninstall spec" over "cave resolve !spec"? According to the cave-uninstall manpage, they are identical.
Regards, Tom Trauth -----Original Message----- From: paludis-user-boun...@lists.pioto.org [mailto:paludis-user-boun...@lists.pioto.org] On Behalf Of John Huttley Sent: Wednesday, February 16, 2011 1:38 PM To: paludis-user@lists.pioto.org Subject: Re: [paludis-user] Removal of deprecated clients This is great! can you put something like this where a user sees it first? how about "cave README_FIRST" > There's a reason it's not called "install": that's not what it does. > > It's also not what 'paludis --install' did, and it's not what 'emerge' > does. Neither paludis nor emerge provide a way to "install a package", > and although it's technically possible to do it using some of the low > level cave commands, it's not something that you really want. > > What 'resolve spec --execute' does is make changes to ensure that 'spec' > is satisfied. To do that, it might install one or more things, and it > might uninstall one or more things. 'resolve' is not the same as > 'install', and 'spec' is not the same as 'package'. > > You might think that they're 'effectively' the same, and that I'm being > pedantic. This isn't the case: equating 'resolve' and 'install' is a > major source of user confusion. Consider: > > ( paludis --install / cave resolve ) one two > > If you read this as 'install one then two' or 'install one and two', > sometimes what you expect will happen. Sometimes it won't, though. > > Consider: > > $command vim vim > > reading it as 'install vim, and install vim' implies that it would > install vim twice, which it won't. Or > > $command vim[>=6] vim[>=7] > > which will again probably only do a single install. Or: > > $command automake > > which might decide to upgrade two different slots. > > There's also the case of "what happens when something fails". If you > read: > > $command first second > > as "install first and second", and if second fails, then you might > expect first to be added to world. But that's not what happens: either > the resolve as a whole succeeds, in which case world is updated, or the > resolve as a whole fails, in which case it isn't. > > Then there's something like: > > $command new-foo > > where new-foo blocks old-foo and auto blocker resolution is enabled. > Again, it's misleading to call that an 'install'. > > So we're left with the situation where users can either think of > "installing a package", in which case the package manager will often > not do what they expect, or where we persuade users to change the way > they think about things so they "resolve a spec" instead. I really > don't think we should be encouraging the mental disconnect, even if it > means users have to spend an extra couple of minutes looking at the > documentation. > _______________________________________________ paludis-user mailing list paludis-user@lists.pioto.org http://lists.pioto.org/mailman/listinfo/paludis-user _______________________________________________ paludis-user mailing list paludis-user@lists.pioto.org http://lists.pioto.org/mailman/listinfo/paludis-user
