1 |
On Mon, 18 May 2009 20:05:51 +0200 |
2 |
Maciej Mrozowski <reavertm@××××××.fm> wrote: |
3 |
> > That's not in the least bit well defined, and it's also extremely |
4 |
> > dangerous. |
5 |
> |
6 |
> Please elaborate on that. |
7 |
|
8 |
With Portage's soft blocks, there's no guarantee that your blocks will |
9 |
do anything at all. Soft blocks are ignored if "they'll be fixed |
10 |
later", but then there's no guarantee that later will be reached. |
11 |
|
12 |
> Everything else like things installed temporarily, no longer pulled |
13 |
> packages, are subject of 'depclean'. I don't see why pruning those |
14 |
> you consider extremely dangerous - especially when there are |
15 |
> parameters like --pretend or --ask. |
16 |
|
17 |
It's unrealistic to assume that depclean's going to be accurate at |
18 |
every given moment, especially given Portage's massively overoptimistic |
19 |
treatment of slots. It's also a very bad idea to remove packages |
20 |
without the user explicitly giving permission to do so. |
21 |
|
22 |
> > > Zac did good job there saving users (especially KDE users) from |
23 |
> > > nightmare of handling all package refactoring/blocks manually. |
24 |
> > |
25 |
> > The nightmare only existed because of abuse of that feature. Had |
26 |
> > blocks kept their original meaning, people would not have abused |
27 |
> > them to the same extent. |
28 |
> |
29 |
> Unfortunately in packaging of dynamically developed applications like |
30 |
> whole KDE environment (with Gentoo KDE split package policy - ~250 |
31 |
> ebuilds with every release) it's impossible not to 'abuse' blocks - |
32 |
> either to handle file collisions issues, or removed/moved libraries |
33 |
> (by upstream). Not sure what was original meaning of blocks you're |
34 |
> referring to, either way - there is no rule stating ">= N uses of |
35 |
> feature X in scope Y in time frame T is considered abuse" |
36 |
|
37 |
Blocks are supposed to be an absolute last resort, not something you |
38 |
throw around willy-nilly to try to get Portage to do what you're after. |
39 |
|
40 |
> - that being said, I'm surprised you're looking for cheap excuse for |
41 |
> providing no working block auto-resolution mechanism (or maybe there |
42 |
> is some I'm not aware of) - it does not need to be in any Gentoo |
43 |
> specification after all - just to make things easier for users. |
44 |
|
45 |
Bah. I'm looking for a way of doing this properly, as I was before Zac |
46 |
went and broke blockers in Portage. Such a way would: |
47 |
|
48 |
* work by explaining the reason for the blocker, rather than sort-of |
49 |
stating the expected resolution. |
50 |
|
51 |
* provide mechanisms for explaining the block in detail to the user, |
52 |
along with instructions on how to resolve it. |
53 |
|
54 |
* be based around tree requirements, not some side effects of some code |
55 |
someone happened to write without considering the implications. |
56 |
|
57 |
-- |
58 |
Ciaran McCreesh |