| 1 |
On Monday 18 of May 2009 19:26:58 Ciaran McCreesh wrote: |
| 2 |
> On Mon, 18 May 2009 19:15:59 +0200 |
| 3 |
> |
| 4 |
> Maciej Mrozowski <reavertm@××××××.fm> wrote: |
| 5 |
> > Not sure who is 'we' there, but Portage team already made is useful. |
| 6 |
> > Basic portage rule for soft-blocks behaviour is "no longer referenced |
| 7 |
> > (a'ka 'soft') blocked package can be uninstalled cleanly without user |
| 8 |
> > intervention" |
| 9 |
> |
| 10 |
> That's not in the least bit well defined, and it's also extremely |
| 11 |
> dangerous. |
| 12 |
|
| 13 |
Please elaborate on that. |
| 14 |
(to make it simple, let me use portage terminology below) |
| 15 |
Everything what user should be interested in is expected to be in 'world' file |
| 16 |
or 'world_sets' or pulled as dependencies. This I define by "referenced". |
| 17 |
Everything else like things installed temporarily, no longer pulled packages, |
| 18 |
are subject of 'depclean'. I don't see why pruning those you consider |
| 19 |
extremely dangerous - especially when there are parameters like --pretend or |
| 20 |
--ask. |
| 21 |
While "no longer referenced" term may be considered not fully defined as it |
| 22 |
does not specify the way things become not referenced anymore (as packages may |
| 23 |
be determined to be referenced later, during block resolution stage, but |
| 24 |
that's implementation specific) - the term "referenced" is defined well |
| 25 |
enough. |
| 26 |
Nobody is (for now) expecting every PMS compliant package manager to return |
| 27 |
identical dependency graph in corner cases. |
| 28 |
|
| 29 |
> > Zac did good job there saving users (especially KDE users) from |
| 30 |
> > nightmare of handling all package refactoring/blocks manually. |
| 31 |
> |
| 32 |
> The nightmare only existed because of abuse of that feature. Had blocks |
| 33 |
> kept their original meaning, people would not have abused them to the |
| 34 |
> same extent. |
| 35 |
|
| 36 |
Unfortunately in packaging of dynamically developed applications like whole |
| 37 |
KDE environment (with Gentoo KDE split package policy - ~250 ebuilds with |
| 38 |
every release) it's impossible not to 'abuse' blocks - either to handle file |
| 39 |
collisions issues, or removed/moved libraries (by upstream). Not sure what was |
| 40 |
original meaning of blocks you're referring to, either way - there is no rule |
| 41 |
stating ">= N uses of feature X in scope Y in time frame T is considered |
| 42 |
abuse" - that being said, I'm surprised you're looking for cheap excuse for |
| 43 |
providing no working block auto-resolution mechanism (or maybe there is some |
| 44 |
I'm not aware of) - it does not need to be in any Gentoo specification after |
| 45 |
all - just to make things easier for users. |
| 46 |
|
| 47 |
-- |
| 48 |
regards |
| 49 |
MM |
| 50 |
|
| 51 |
---------------------------------------------------------------------- |
| 52 |
Zrob sobie prezent. Wygraj nagrode! |
| 53 |
Sprawdz >> http://link.interia.pl/f2176 |
Archives