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