From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M69sA-0004UF-W4 for garchives@archives.gentoo.org; Mon, 18 May 2009 20:55:47 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6B4EDE0303; Mon, 18 May 2009 20:55:45 +0000 (UTC) Received: from ey-out-1920.google.com (ey-out-1920.google.com [74.125.78.144]) by pigeon.gentoo.org (Postfix) with ESMTP id 09310E0303 for ; Mon, 18 May 2009 20:55:44 +0000 (UTC) Received: by ey-out-1920.google.com with SMTP id 26so892088eyw.10 for ; Mon, 18 May 2009 13:55:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=3pVW0CrP/27ixiiSP5zu+skKuvVg2UCwrswbburlOO0=; b=xCzbAPm0mcHnU90UPWM5iZj2TcGVCebFQehyga2bqxyOKjXHOb8VnjMBSiKXDgkTRg dak5iOkXCYjT7Ah5ilfutubb+rvQigDofUOLqNTZAbTjbRz6vgRMbWZMieyKJiGNjePL 8G5XvIHIO7Qu7oKRmRTsA8zNHoEYZDny/+2AU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=eKsoCOZis4VQ4LI81mXwlTyQtZzicq7jc+GeO4cAWmEVMil3MgkVuhV8ZZkjwN0wzS zkMyKhTgCJp4UWyU8XjBasHLOCltH7CWD0gh0q8Q34KdFvxkHtKFpTSN6R2xGO3633Mj XSDWJUIM47dHAzAuEufSTMPwHd+q/n52DvJsU= Received: by 10.210.19.7 with SMTP id 7mr4851671ebs.93.1242680144150; Mon, 18 May 2009 13:55:44 -0700 (PDT) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id 28sm157380eyg.44.2009.05.18.13.55.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 13:55:43 -0700 (PDT) Date: Mon, 18 May 2009 21:55:38 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] blocking mixed versions of split QT libraries Message-ID: <20090518215538.69909604@snowcone> In-Reply-To: <200905182247.30368.patrick@gentoo.org> References: <225000070905180304u49e9a50btcc0f8935368afc03@mail.gmail.com> <200905182108.25543.patrick@gentoo.org> <20090518202010.16cdf6ff@snowcone> <200905182247.30368.patrick@gentoo.org> X-Mailer: Claws Mail 3.7.1 (GTK+ 2.14.7; x86_64-pc-linux-gnu) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=PGP-SHA1; boundary="Sig_/uu4UejKrFZK2R0dxDqHdvzF"; protocol="application/pgp-signature" X-Archives-Salt: 08a72785-dcb5-43ec-8667-a54a8ca22cb1 X-Archives-Hash: dca6fe59e6980081b08707caa4f58776 --Sig_/uu4UejKrFZK2R0dxDqHdvzF Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 18 May 2009 22:47:30 +0200 Patrick Lauer 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.=20 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!).=20 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. --=20 Ciaran McCreesh --Sig_/uu4UejKrFZK2R0dxDqHdvzF Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoRy0wACgkQ96zL6DUtXhHY4QCgmtwq7BVEHGUiUm8abR09CvA4 pm4AoNi3QkR8GZ/Ezd8JNtqX6/cig64W =FAL+ -----END PGP SIGNATURE----- --Sig_/uu4UejKrFZK2R0dxDqHdvzF--