On Wed, 16 Apr 2008 07:54:48 +0200
"Mateusz A. Mierzwin'ski" <mateuszmierzwinski@...> wrote:
> And I strongly suggest to leave old mechanism of portage, because we
> saw couple times what _GREAT_ automatic makes with distro - eg.
> Mandriva with all creators and cheap installer - couple apps not
> running, low performance.
> 
> Don't get me wrong - I also have that problems, and they make me 
> nervous, but when I think what could I done by automatic replace
> package or binary then I get to thinking that everything is ok...

I'm not suggesting automatic anything. Here's what I am suggesting.

Case A, Current Behaviour: User tries to install superfoo. User has
foobar installed. User is presented with a big red blocking message,
with no explanation. User has to work out that he is expected to
uninstall foobar, then install superfoo (which is a problem if superfoo
fails).

Case A, Suggested New Behaviour: User is instead presented with
something like this:

    [block] app-misc/foobar is blocking app-misc/superfoo.
        Explanation: foobar and superfoo both provide /usr/bin/foo
        More information: http://www.gentoo.org/blah/blah.xml
    [install] app-misc/superfoo
    [uninstall] app-misc/foobar

    Error: the above resolution will uninstall 1 package. To accept
    this uninstall, use --permit-uninstalls.

Case B is similar to Case A in resolution, but it's probably nice to
make the distinction.

Case C, Current Behaviour: User tries to upgrade foo. User is presented
with a big red blocking message saying foo blocks libfoo or libfoo
blocks foo, with no explanation (assuming it's not one of the subset of
issues that can be solved automatically).

Case C, Suggested New Behaviour: The package manager realises that so
long as both foo and libfoo are upgraded during the same session,
there's no real block, and the block is merely a way of getting around
limitations in collision detection. No block is shown to the user.

Case D, Current Behaviour: User tries to upgrade coreutils. User gets a
big flashy block error saying coreutils blocks mktemp. User doesn't
realise that the safe upgrade path is to force the package manager to
ignore the block, then manually uninstall mktemp straight afterwards.
User instead uninstalls mktemp, which is a moderately critical binary.

Case D, Suggested New Behaviour: User is presented with something like
this:

    [block] sys-apps/coreutils is blocking sys-apps/mktemp
        Explanation: mktemp is now part of coreutils
        More information: http://www.gentoo.org/blah/blah.xml
    [upgrade] sys-apps/coreutils
    [uninstall] sys-apps/mktemp

    Error: the above resolution will uninstall 1 package. To accept
    this uninstall, use --permit-uninstalls.

Note how mktemp is uninstalled *after* coreutils has been upgraded.

In none of these scenarios is it necessary to uninstall the blocked
package before installing the package doing the blocking. But such
scenarios probably exist, and ideally we'd have nice ways of dealing
with that, so I'd like to know what all the current and projected
future uses for blockers are.

-- 
Ciaran McCreesh