-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ciaran McCreesh wrote:
| 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
|
Very good idea.
- --
Luis F. Araujo "araujo at gentoo.org"
Gentoo Linux
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEARECAAYFAkgFl1AACgkQBCmRZan6aeg9wwCdE0tOEUtinfV5iUyxqQbuKFG5
O1MAoIgUmY5HTLNMgDAaYtgKvm4Me4ru
=T31v
-----END PGP SIGNATURE-----
--
gentoo-dev@g.o mailing list
|
