1 |
On Wed, 16 Apr 2008 07:54:48 +0200 |
2 |
"Mateusz A. Mierzwin'ski" <mateuszmierzwinski@××.pl> wrote: |
3 |
> And I strongly suggest to leave old mechanism of portage, because we |
4 |
> saw couple times what _GREAT_ automatic makes with distro - eg. |
5 |
> Mandriva with all creators and cheap installer - couple apps not |
6 |
> running, low performance. |
7 |
> |
8 |
> Don't get me wrong - I also have that problems, and they make me |
9 |
> nervous, but when I think what could I done by automatic replace |
10 |
> package or binary then I get to thinking that everything is ok... |
11 |
|
12 |
I'm not suggesting automatic anything. Here's what I am suggesting. |
13 |
|
14 |
Case A, Current Behaviour: User tries to install superfoo. User has |
15 |
foobar installed. User is presented with a big red blocking message, |
16 |
with no explanation. User has to work out that he is expected to |
17 |
uninstall foobar, then install superfoo (which is a problem if superfoo |
18 |
fails). |
19 |
|
20 |
Case A, Suggested New Behaviour: User is instead presented with |
21 |
something like this: |
22 |
|
23 |
[block] app-misc/foobar is blocking app-misc/superfoo. |
24 |
Explanation: foobar and superfoo both provide /usr/bin/foo |
25 |
More information: http://www.gentoo.org/blah/blah.xml |
26 |
[install] app-misc/superfoo |
27 |
[uninstall] app-misc/foobar |
28 |
|
29 |
Error: the above resolution will uninstall 1 package. To accept |
30 |
this uninstall, use --permit-uninstalls. |
31 |
|
32 |
Case B is similar to Case A in resolution, but it's probably nice to |
33 |
make the distinction. |
34 |
|
35 |
Case C, Current Behaviour: User tries to upgrade foo. User is presented |
36 |
with a big red blocking message saying foo blocks libfoo or libfoo |
37 |
blocks foo, with no explanation (assuming it's not one of the subset of |
38 |
issues that can be solved automatically). |
39 |
|
40 |
Case C, Suggested New Behaviour: The package manager realises that so |
41 |
long as both foo and libfoo are upgraded during the same session, |
42 |
there's no real block, and the block is merely a way of getting around |
43 |
limitations in collision detection. No block is shown to the user. |
44 |
|
45 |
Case D, Current Behaviour: User tries to upgrade coreutils. User gets a |
46 |
big flashy block error saying coreutils blocks mktemp. User doesn't |
47 |
realise that the safe upgrade path is to force the package manager to |
48 |
ignore the block, then manually uninstall mktemp straight afterwards. |
49 |
User instead uninstalls mktemp, which is a moderately critical binary. |
50 |
|
51 |
Case D, Suggested New Behaviour: User is presented with something like |
52 |
this: |
53 |
|
54 |
[block] sys-apps/coreutils is blocking sys-apps/mktemp |
55 |
Explanation: mktemp is now part of coreutils |
56 |
More information: http://www.gentoo.org/blah/blah.xml |
57 |
[upgrade] sys-apps/coreutils |
58 |
[uninstall] sys-apps/mktemp |
59 |
|
60 |
Error: the above resolution will uninstall 1 package. To accept |
61 |
this uninstall, use --permit-uninstalls. |
62 |
|
63 |
Note how mktemp is uninstalled *after* coreutils has been upgraded. |
64 |
|
65 |
In none of these scenarios is it necessary to uninstall the blocked |
66 |
package before installing the package doing the blocking. But such |
67 |
scenarios probably exist, and ideally we'd have nice ways of dealing |
68 |
with that, so I'd like to know what all the current and projected |
69 |
future uses for blockers are. |
70 |
|
71 |
-- |
72 |
Ciaran McCreesh |