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 1M68Nm-0006j4-QR for garchives@archives.gentoo.org; Mon, 18 May 2009 19:20:19 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 76226E035D; Mon, 18 May 2009 19:20:17 +0000 (UTC) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.157]) by pigeon.gentoo.org (Postfix) with ESMTP id 1BDC9E035D for ; Mon, 18 May 2009 19:20:16 +0000 (UTC) Received: by fg-out-1718.google.com with SMTP id 13so1269187fge.14 for ; Mon, 18 May 2009 12:20:16 -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=vmDlMvM14Extx5Po9EsO9VYjQfIgywHgAMvmBzg8il4=; b=Yy6yt7Q5pgn/GWdT8I9ff7RjhVTPw5r7hUYB9b1CmlxExf71OO6PnUVQ80ADZ6Uz/+ Fp+Vwphh27HTxTiq9p15gmxy7YloWjwwLBYZj2pHoh+VTPlFS73dD0BGwOBC4v5Zqkvk JmU4HoCDcB7v5kS26Mej3GTLWn59HqsuX9rOI= 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=tBrGIcbYbY8LsVlb1BunrOo6sVAivL9jc1SuiJLz3lMMNE2SnfgwsyXa59rtWfhGRu aPGIS1xC0Y2o2jfqGSOmSi2iq7Rzgq/vsYkUAJi9lry42mC/TBCCE7heClfjQ+m3jnF+ EGxyYEQHfiEogOzXL1Xk9tIKr0XX3dSQhb3r0= Received: by 10.86.79.6 with SMTP id c6mr7038986fgb.52.1242674416378; Mon, 18 May 2009 12:20:16 -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 e11sm5341273fga.16.2009.05.18.12.20.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 12:20:16 -0700 (PDT) Date: Mon, 18 May 2009 20:20:10 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] blocking mixed versions of split QT libraries Message-ID: <20090518202010.16cdf6ff@snowcone> In-Reply-To: <200905182108.25543.patrick@gentoo.org> References: <225000070905180304u49e9a50btcc0f8935368afc03@mail.gmail.com> <200905182005.51818.reavertm@poczta.fm> <20090518191924.3c650519@snowcone> <200905182108.25543.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_/n4LW/yoHoh4cRxoZU73_Mai"; protocol="application/pgp-signature" X-Archives-Salt: 96144d9e-03fd-483c-917b-973575ebc8f7 X-Archives-Hash: e8be28802076392e500a2edc6023dead --Sig_/n4LW/yoHoh4cRxoZU73_Mai Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 18 May 2009 21:08:25 +0200 Patrick Lauer 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.=20 > 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. --=20 Ciaran McCreesh --Sig_/n4LW/yoHoh4cRxoZU73_Mai Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoRtO0ACgkQ96zL6DUtXhHxjwCgzyhPV8aA29fb0grOm7Adhrdg 4aQAoL7OkP/4hHdfqNqUbjaBCYg30XNE =v8B5 -----END PGP SIGNATURE----- --Sig_/n4LW/yoHoh4cRxoZU73_Mai--