Re: [gentoo-dev] blocking mixed versions of split QT libraries

[Ciaran McCreesh]

On Mon, 18 May 2009 21:08:25 +0200
Patrick Lauer <patrick@g.o> wrote:
> 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.

No, they're temporary except when things go wrong, at which point
there's no indication that they'll be fixed.

> > 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.

Look at the new slot deps in EAPI 3.

> > 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/

No, broke. What he did was in direct violation of PMS and in direct
violation of assumptions made by many packages.

> > * 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.

Uhm. Knowing the reason for the block lets the package manager solve
the problem in the most intelligent available way. Merely being sort-of
told the expected resolution does not.

> > * 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?

Automated resolution is not always possible or a good idea. Also,
having more information available for the user and being able to
suggest an automated resolution are not in the least bit contradictory.

> > * 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)

A tree requirement is one that comes about as a result of studying what
ebuilds do now and what they'd like to do in the future, rather than
one that comes around based upon what someone happens to code.

> 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.

...except for the things that it broke, which necessitated shoving !!
blocks in at the last minute. And I'll remind you that there were
discussions about a proper blocker solution before Zac went and did his
thing, and the overwhelming view was that a solution based around the
things I've been discussing was what was wanted.

> 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.

See the discussions we had back when the only kind of blocker was a
hard, single ! block.

-- 
Ciaran McCreesh