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 1Jm1nf-0006cH-7b for garchives@archives.gentoo.org; Wed, 16 Apr 2008 07:11:23 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 274A6E04A4; Wed, 16 Apr 2008 07:11:21 +0000 (UTC) Received: from rs25s12.datacenter.cha.cantv.net (rs25s12.datacenter.cha.cantv.net [200.44.33.35]) by pigeon.gentoo.org (Postfix) with ESMTP id CCD7BE04A4 for ; Wed, 16 Apr 2008 07:11:20 +0000 (UTC) X-DNSBL-MILTER: Passed Received: from localhost (dBE25A8E9.dslam-01-3-15-01-1-01.smg.dsl.cantv.net [190.37.168.233]) by rs25s12.datacenter.cha.cantv.net (8.13.8/8.13.0/3.0) with ESMTP id m3G7BJTJ004468 for ; Wed, 16 Apr 2008 02:41:19 -0430 X-Matched-Lists: [] Received: from localhost ([127.0.0.1]) by localhost with esmtp (Exim 4.69) (envelope-from ) id 1Jm0mW-00049m-Kq for gentoo-dev@lists.gentoo.org; Wed, 16 Apr 2008 02:06:08 -0400 Message-ID: <48059750.60901@gentoo.org> Date: Wed, 16 Apr 2008 02:06:08 -0400 From: Luis Francisco Araujo User-Agent: Thunderbird 2.0.0.12 (X11/20080305) 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] What are blocks used for? References: <20080416062452.45f3831d@snowcone> <480594A8.80105@o2.pl> <20080416073411.6f52a629@snowcone> In-Reply-To: <20080416073411.6f52a629@snowcone> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on 10.128.1.88 X-Virus-Status: Clean X-Archives-Salt: ffa47429-a174-4a7e-aeea-fe1a2bb85a83 X-Archives-Hash: b75cfb00fa12977f9d38a90d91b01879 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: | 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. |> |> Don't get me wrong - I also have that problems, and they make me |> 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 | Very good idea. - -- Luis F. Araujo "araujo at gentoo.org" Gentoo Linux -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkgFl1AACgkQBCmRZan6aeg9wwCdE0tOEUtinfV5iUyxqQbuKFG5 O1MAoIgUmY5HTLNMgDAaYtgKvm4Me4ru =T31v -----END PGP SIGNATURE----- -- gentoo-dev@lists.gentoo.org mailing list