[paludis-user] Removal of deprecated clients

Ciaran McCreesh ciaran.mccreesh at googlemail.com
Wed Feb 16 15:03:50 UTC 2011

On Wed, 16 Feb 2011 12:10:23 +1300
John Huttley <John at mib-infotech.co.nz> wrote:
> It's a complete fail of 1 & 2 above.
> How-to-install-or-update-a-package, which is absolutely and
> unarguably the most important thing a package manager can do, is not
> mentioned. There should be entire _screeds_ on that.

There's not much to it. The synopsis in 'man cave-resolve' should do.

> Markus has informed me that "resolve" is the new install.  Wonderful.
> I would never have guessed.

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.


    $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

    $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

> I suggest that a rewrite of paludis.pioto.org is in order and top  of 
> the list is "how to do common tasks with cave". Portage version,
> because everyone starts there, paludis version (note that its soon to
> be extinct) and cave version.

There is no equivalence of commands between package managers. And you
shouldn't be copy-pasting recipes; you should be understanding what
you're asking the package manager to do.

Ciaran McCreesh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.exherbo.org/pipermail/paludis-user/attachments/20110216/ac5551cd/attachment.asc>

More information about the paludis-user mailing list