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 1M67Qy-0006P9-LN for garchives@archives.gentoo.org; Mon, 18 May 2009 18:19:32 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 1E1C1E01C3; Mon, 18 May 2009 18:19:31 +0000 (UTC) Received: from ey-out-1920.google.com (ey-out-1920.google.com [74.125.78.149]) by pigeon.gentoo.org (Postfix) with ESMTP id B97CAE01C3 for ; Mon, 18 May 2009 18:19:30 +0000 (UTC) Received: by ey-out-1920.google.com with SMTP id 26so867205eyw.10 for ; Mon, 18 May 2009 11:19:30 -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=8rJ7YPueTBtUDs9J1DBZs36DG53Z51QOYklILnrEVZs=; b=HmE4kCWiREEnZQxmPXakKfhqZblgSMH3CIWyXKb1ttZUtN2S3NyvuEZoCW9snGWQNv wAakyioNmdNwM4Hh5LvV2vOnZkfbChg3kJ22qh/DWeaadI7viVRZZO8HKkegk8cTeXa9 U/Y2Y94pKy9GqoUR2N3kimK32ergftTdKTWPQ= 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=ZZ3VZ65coA7+O8ebFV6M/zIhlYacULvyOG3piWIvHj9BtrFO+xMHYpp0EEhqNE0qf1 0FRWtttd0LCF65l6CtYGESNo9LxhaJe3XWBfIznNZBt/WxCsQoYr4b48dOhWhVaXrmmX lksQk+eWFABVrUCqDxvOyLNtgmU1HW8VNLkUM= Received: by 10.210.111.17 with SMTP id j17mr1727851ebc.74.1242670770058; Mon, 18 May 2009 11:19:30 -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 10sm6483415eyd.12.2009.05.18.11.19.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 18 May 2009 11:19:29 -0700 (PDT) Date: Mon, 18 May 2009 19:19:24 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] blocking mixed versions of split QT libraries Message-ID: <20090518191924.3c650519@snowcone> In-Reply-To: <200905182005.51818.reavertm@poczta.fm> References: <225000070905180304u49e9a50btcc0f8935368afc03@mail.gmail.com> <200905181916.00201.reavertm@poczta.fm> <20090518182658.16c2eccf@snowcone> <200905182005.51818.reavertm@poczta.fm> 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_/b6ixT1exKJ1iIYXWuetpb6I"; protocol="application/pgp-signature" X-Archives-Salt: a0815ab1-a890-4bf8-abc0-6a3229263b15 X-Archives-Hash: 882a5d6d3a67ba6ad36a83735d1d278d --Sig_/b6ixT1exKJ1iIYXWuetpb6I Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Mon, 18 May 2009 20:05:51 +0200 Maciej Mrozowski wrote: > > That's not in the least bit well defined, and it's also extremely > > dangerous. >=20 > 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. > 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. > > > Zac did good job there saving users (especially KDE users) from > > > nightmare of handling all package refactoring/blocks manually. > > > > The nightmare only existed because of abuse of that feature. Had > > blocks kept their original meaning, people would not have abused > > them to the same extent. >=20 > Unfortunately in packaging of dynamically developed applications like > whole KDE environment (with Gentoo KDE split package policy - ~250 > ebuilds with every release) it's impossible not to 'abuse' blocks - > either to handle file collisions issues, or removed/moved libraries > (by upstream). Not sure what was original meaning of blocks you're > referring to, either way - there is no rule stating ">=3D N uses of > feature X in scope Y in time frame T is considered abuse" 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. > - 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. Such a way would: * work by explaining the reason for the blocker, rather than sort-of stating the expected resolution. * provide mechanisms for explaining the block in detail to the user, along with instructions on how to resolve it. * be based around tree requirements, not some side effects of some code someone happened to write without considering the implications. --=20 Ciaran McCreesh --Sig_/b6ixT1exKJ1iIYXWuetpb6I Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkoRpq8ACgkQ96zL6DUtXhHeFACbBlH2RcY7nn7LDXKuhWMvFU1G d4IAmgMBIa67Zlb9CRJ3pXv9dx6I4HIy =9gN+ -----END PGP SIGNATURE----- --Sig_/b6ixT1exKJ1iIYXWuetpb6I--