On Monday 18 May 2009 20:19:24 Ciaran McCreesh wrote:
> On Mon, 18 May 2009 20:05:51 +0200
>
> Maciej Mrozowski <reave...@poczta.fm> 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.
In terms of the on-disk result it's invariant, the result is what you'd
expect. There are intermediate stages that are "inconsistent" / "unclean", but
as these are known and temporary they are an acceptable solution.
> > 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.
Which either means that the deps are wrong/incomplete or that portage has
algorithmic flaws which should be corrected.
I'd expect you to at least point to the relevant bugs and not just state some
emotional mumbo-jumbo.
Plus the packages that are removed were not installed explicitly, and to
satisfy the needs of the user they are removed. This reflects the demands of
the user ("Give me this app!" or "Update this pile of apps!") quite well.
> 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.
No, blocks are what you need to keep the set of installed packages consistent.
They need to be used as much as the flaws and conflicts of software packaging
require.
Any emotional statement like "last resort", "obviously", "willy-nilly" or
"cute" has no place in a discussion about needed technical features.
> > - 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.
s/broke/fixed/
> Such a way would:
>
> * work by explaining the reason for the blocker, rather than sort-of
> stating the expected resolution.
That's dumb ;) (Sorry, emotional statement)
I mean, it does not help to solve the issue and requires user interaction
where an automated solution has been working reliably for quite some time.
Providing extra information would be nice, but causes more work for the
package maintainer and the user for little benefit.
> * provide mechanisms for explaining the block in detail to the user,
> along with instructions on how to resolve it.
User interaction where automated resolution works sounds like a step backwards
to me. Maybe refining the rules for automated resolution would be a more
appropriate solution?
> * be based around tree requirements, not some side effects of some code
> someone happened to write without considering the implications.
What is a tree requirement? (Nice buzzword btw)
And as many devs and users benefit quite a lot from the portage solution,
which zmedico did not dream up without thinking about the impact on users, I
find it very rude and condescending of you to disrespect the solution without
offering an alternative.
As you seem to understand the problem domain I'd expect a coherent unambiguous
proposal instead of vague accusations and emotional terms that do not help in
any way to improve the situation.
