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

[Ciaran McCreesh <ciaran.mccreesh@googlemail.com>]

[-- Attachment #1: Type: text/plain, Size: 5030 bytes --]

On Mon, 18 May 2009 22:47:30 +0200
Patrick Lauer <patrick@gentoo.org> wrote:
> > No, they're temporary except when things go wrong, at which point
> > there's no indication that they'll be fixed.
> >
> When things go wrong they go wrong. Indeed.

When things go wrong, they go wrong beyond the scope of the failure in
question.

> > > 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.
> So the deps were not precise enough, and now we improve that. Which
> means that portage will only get more precise in the future. Awesome!

...and until they're in wide use, Portage's assumptions are dangerous.

> > No, broke. What he did was in direct violation of PMS and in direct
> > violation of assumptions made by many packages.
> So PMS did once again not reflect reality, and there were some buggy
> packages.

Uhm. No. PMS reflected how Portage used to work, and packages relied
upon how Portage used to work.

> Maybe we should spend more time on making PMS a standard
> that documents current and past behavior instead of omitting things
> (mtime, bash 3.1) or keeping it ambiguous so that two implementations
> can be compliant while delivering incompatible results?

Uhm. PMS correctly reflects current and past behaviour on those issues.

> > > > * 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.
> You're contradicting yourself there - until now you only mentioned
> user- visible messages, which now suddenly become hints for the
> package manager. 

Re-read what I said, alongside the original discussion on replacing
blockers. "Explaining" is not exclusively limited to the user.

> Now I do wonder what you can "explain" about a block - "some files
> collide" ? How does that help the package manager decide what to do?
> What can it do, except unmerging one package or refusing to merge
> another one? How does that differ from the portage solution to the
> blocker situation?

Yes, that's one explanation you'd give to the package manager. As
you'll recall from your reading of the previous discussion, there are
four different ways in which blockers are commonly used, and the
best response from the package manager to each situation is different.

> > 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.
> I am confused. I did not think that ebuilds have desires, so I have
> no idea what they'd like to do in the future. And it does in no way
> tell me what a tree requirement is (unless you mean happy photons,
> which are emitted by free- range ebuilds when you try to source them
> in the kitchen)

Then I suggest you take some basic English classes.

> Incidentally most of our ebuilds are based upon what someone happened
> to code.

But the ebuild design (or at least the clean parts of it...) is not.

> > ...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,
> bikeshedding and circular reasoning in large amounts, stalling any
> progress for a long time ... until someone provided a working
> implementation that solved a large enough amount of issues to gain
> the support of the majority of devs (and big cheers from so many
> users!). 

Funnily enough, the original discussion was extremely productive and
didn't involve any of the nonsense you're coming up with now.

> (If it had been as bad as you suggest council would have
> banninated it within the shortest amount of time...)

That was back in the bad old days before the Council agreed to step in
when Portage did that kind of thing. In fact, the blocker changes were
one of the things that lead to the Council saying "in future, we'll
package.mask Portage if it does that kind of behaviour change again".

> > and the overwhelming view
>
> a minority view, but let's not get distracted by such subjective
> matters.

Please point me to people involved in the discussion who did not agree
with the views presented. Provide a list of message IDs to support your
claim.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]