1 |
On Monday 18 May 2009 20:19:24 Ciaran McCreesh wrote: |
2 |
> On Mon, 18 May 2009 20:05:51 +0200 |
3 |
> |
4 |
> Maciej Mrozowski <reavertm@××××××.fm> wrote: |
5 |
> > > That's not in the least bit well defined, and it's also extremely |
6 |
> > > dangerous. |
7 |
> > |
8 |
> > Please elaborate on that. |
9 |
> |
10 |
> With Portage's soft blocks, there's no guarantee that your blocks will |
11 |
> do anything at all. Soft blocks are ignored if "they'll be fixed |
12 |
> later", but then there's no guarantee that later will be reached. |
13 |
|
14 |
In terms of the on-disk result it's invariant, the result is what you'd |
15 |
expect. There are intermediate stages that are "inconsistent" / "unclean", but |
16 |
as these are known and temporary they are an acceptable solution. |
17 |
|
18 |
> > Everything else like things installed temporarily, no longer pulled |
19 |
> > packages, are subject of 'depclean'. I don't see why pruning those |
20 |
> > you consider extremely dangerous - especially when there are |
21 |
> > parameters like --pretend or --ask. |
22 |
> |
23 |
> It's unrealistic to assume that depclean's going to be accurate at |
24 |
> every given moment, especially given Portage's massively overoptimistic |
25 |
> treatment of slots. It's also a very bad idea to remove packages |
26 |
> without the user explicitly giving permission to do so. |
27 |
Which either means that the deps are wrong/incomplete or that portage has |
28 |
algorithmic flaws which should be corrected. |
29 |
I'd expect you to at least point to the relevant bugs and not just state some |
30 |
emotional mumbo-jumbo. |
31 |
|
32 |
Plus the packages that are removed were not installed explicitly, and to |
33 |
satisfy the needs of the user they are removed. This reflects the demands of |
34 |
the user ("Give me this app!" or "Update this pile of apps!") quite well. |
35 |
|
36 |
> Blocks are supposed to be an absolute last resort, not something you |
37 |
> throw around willy-nilly to try to get Portage to do what you're after. |
38 |
|
39 |
No, blocks are what you need to keep the set of installed packages consistent. |
40 |
They need to be used as much as the flaws and conflicts of software packaging |
41 |
require. |
42 |
Any emotional statement like "last resort", "obviously", "willy-nilly" or |
43 |
"cute" has no place in a discussion about needed technical features. |
44 |
|
45 |
|
46 |
> > - that being said, I'm surprised you're looking for cheap excuse for |
47 |
> > providing no working block auto-resolution mechanism (or maybe there |
48 |
> > is some I'm not aware of) - it does not need to be in any Gentoo |
49 |
> > specification after all - just to make things easier for users. |
50 |
> |
51 |
> Bah. I'm looking for a way of doing this properly, as I was before Zac |
52 |
> went and broke blockers in Portage. |
53 |
s/broke/fixed/ |
54 |
|
55 |
> Such a way would: |
56 |
> |
57 |
> * work by explaining the reason for the blocker, rather than sort-of |
58 |
> stating the expected resolution. |
59 |
That's dumb ;) (Sorry, emotional statement) |
60 |
I mean, it does not help to solve the issue and requires user interaction |
61 |
where an automated solution has been working reliably for quite some time. |
62 |
|
63 |
Providing extra information would be nice, but causes more work for the |
64 |
package maintainer and the user for little benefit. |
65 |
|
66 |
> * provide mechanisms for explaining the block in detail to the user, |
67 |
> along with instructions on how to resolve it. |
68 |
User interaction where automated resolution works sounds like a step backwards |
69 |
to me. Maybe refining the rules for automated resolution would be a more |
70 |
appropriate solution? |
71 |
|
72 |
> * be based around tree requirements, not some side effects of some code |
73 |
> someone happened to write without considering the implications. |
74 |
What is a tree requirement? (Nice buzzword btw) |
75 |
|
76 |
And as many devs and users benefit quite a lot from the portage solution, |
77 |
which zmedico did not dream up without thinking about the impact on users, I |
78 |
find it very rude and condescending of you to disrespect the solution without |
79 |
offering an alternative. |
80 |
|
81 |
As you seem to understand the problem domain I'd expect a coherent unambiguous |
82 |
proposal instead of vague accusations and emotional terms that do not help in |
83 |
any way to improve the situation. |