From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1Jm1Dr-0003p7-71 for garchives@archives.gentoo.org; Wed, 16 Apr 2008 06:34:23 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 84C59E02E5; Wed, 16 Apr 2008 06:34:21 +0000 (UTC) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.233]) by pigeon.gentoo.org (Postfix) with ESMTP id 24397E046E for ; Wed, 16 Apr 2008 06:34:21 +0000 (UTC) Received: by hu-out-0506.google.com with SMTP id 23so1894193huc.1 for ; Tue, 15 Apr 2008 23:34:20 -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=F7KuXGVOYmWtoTtUjBKyYEXiAn+ls5/vH/EAssgf1+Q=; b=XwgBkDrOvwvd+LSL01AX6g3MAzVKzVCvNu2ykY/mxVX98LgXffjtjxn3vfGgtRzd/9SdhISFXbvnJtpmh9CwL7UxOn2f6B63w2w7q1iT/K8ZBGowkg83SRR8JnV408xnRuvcw6hSkoJCdbQgNEmkHu1sXdXSWHGn+bJNuI+Hhes= 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=QrkaY6/3Id+1vFDUpHXbmYjB0HKtPzH14amuc8el45SSchBuckrw8ww9eAbNiE+YDfDuIdjsg3t+W2bpwXlb2nh44ofKINc4F6OXfZCj4iJvHM9FHLUtdXZh12PuWesrd4BmqiYJQ96Xyd2bMt3iVmcyfh6DGVs9N833AZkNQ+k= Received: by 10.86.96.18 with SMTP id t18mr17968476fgb.13.1208327659930; Tue, 15 Apr 2008 23:34:19 -0700 (PDT) Received: from snowcone ( [213.121.151.206]) by mx.google.com with ESMTPS id d6sm7325528fga.9.2008.04.15.23.34.18 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 15 Apr 2008 23:34:19 -0700 (PDT) Date: Wed, 16 Apr 2008 07:34:11 +0100 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] What are blocks used for? Message-ID: <20080416073411.6f52a629@snowcone> In-Reply-To: <480594A8.80105@o2.pl> References: <20080416062452.45f3831d@snowcone> <480594A8.80105@o2.pl> X-Mailer: Claws Mail 3.3.1 (GTK+ 2.12.9; 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; boundary="Sig_/OR9Wq3f64_t5Tb4t1DEJ+C0"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: e6e73bd6-39db-4d4a-be0b-ee7ab4a76891 X-Archives-Hash: 184f4ae18889ea692630cab87a7bc08f --Sig_/OR9Wq3f64_t5Tb4t1DEJ+C0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Wed, 16 Apr 2008 07:54:48 +0200 "Mateusz A. Mierzwin'ski" wrote: > And I strongly suggest to leave old mechanism of portage, because we > saw couple times what _GREAT_ automatic makes with distro - eg. > Mandriva with all creators and cheap installer - couple apps not > running, low performance. >=20 > Don't get me wrong - I also have that problems, and they make me=20 > nervous, but when I think what could I done by automatic replace > package or binary then I get to thinking that everything is ok... I'm not suggesting automatic anything. Here's what I am suggesting. Case A, Current Behaviour: User tries to install superfoo. User has foobar installed. User is presented with a big red blocking message, with no explanation. User has to work out that he is expected to uninstall foobar, then install superfoo (which is a problem if superfoo fails). Case A, Suggested New Behaviour: User is instead presented with something like this: [block] app-misc/foobar is blocking app-misc/superfoo. Explanation: foobar and superfoo both provide /usr/bin/foo More information: http://www.gentoo.org/blah/blah.xml [install] app-misc/superfoo [uninstall] app-misc/foobar Error: the above resolution will uninstall 1 package. To accept this uninstall, use --permit-uninstalls. Case B is similar to Case A in resolution, but it's probably nice to make the distinction. Case C, Current Behaviour: User tries to upgrade foo. User is presented with a big red blocking message saying foo blocks libfoo or libfoo blocks foo, with no explanation (assuming it's not one of the subset of issues that can be solved automatically). Case C, Suggested New Behaviour: The package manager realises that so long as both foo and libfoo are upgraded during the same session, there's no real block, and the block is merely a way of getting around limitations in collision detection. No block is shown to the user. Case D, Current Behaviour: User tries to upgrade coreutils. User gets a big flashy block error saying coreutils blocks mktemp. User doesn't realise that the safe upgrade path is to force the package manager to ignore the block, then manually uninstall mktemp straight afterwards. User instead uninstalls mktemp, which is a moderately critical binary. Case D, Suggested New Behaviour: User is presented with something like this: [block] sys-apps/coreutils is blocking sys-apps/mktemp Explanation: mktemp is now part of coreutils More information: http://www.gentoo.org/blah/blah.xml [upgrade] sys-apps/coreutils [uninstall] sys-apps/mktemp Error: the above resolution will uninstall 1 package. To accept this uninstall, use --permit-uninstalls. Note how mktemp is uninstalled *after* coreutils has been upgraded. In none of these scenarios is it necessary to uninstall the blocked package before installing the package doing the blocking. But such scenarios probably exist, and ideally we'd have nice ways of dealing with that, so I'd like to know what all the current and projected future uses for blockers are. --=20 Ciaran McCreesh --Sig_/OR9Wq3f64_t5Tb4t1DEJ+C0 Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFIBZ3m96zL6DUtXhERAmRpAJ0XyfuXAQeliOkoIFy51n06gyzsiACfaE05 maKpumzsQXhd7qPsdnh1Qn4= =r/ie -----END PGP SIGNATURE----- --Sig_/OR9Wq3f64_t5Tb4t1DEJ+C0-- -- gentoo-dev@lists.gentoo.org mailing list