From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 0B8AD1396D9 for ; Sun, 29 Oct 2017 00:10:13 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BA710E0EB5; Sun, 29 Oct 2017 00:10:07 +0000 (UTC) Received: from auth-3.ukservers.net (auth-3.ukservers.net [217.10.138.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 5C0ACE0EAC for ; Sun, 29 Oct 2017 00:10:07 +0000 (UTC) Received: from [192.168.1.64] (host86-184-51-38.range86-184.btcentralplus.com [86.184.51.38]) by auth-3.ukservers.net (Postfix smtp) with ESMTPA id 7741E5412F7 for ; Sun, 29 Oct 2017 01:10:03 +0100 (BST) Subject: Re: [gentoo-user] A portage nuisance To: gentoo-user@lists.gentoo.org References: <424ad9$4d4mm2@relay.skynet.be> <20171027145813.3a4fac70@peak.prhnet> <20171028175212.2fb3d76b5c3bcb8863fa00c7@gentoo.org> <59F4C549.6010507@youngman.org.uk> <285a551b-27a5-3a5d-dc5c-912a67e5d015@youngman.org.uk> <9ebcd8df-d618-5fe4-3858-41ae41862588@gmail.com> <1ca4aac2-020f-3a54-4612-e4c230bea3ca@youngman.org.uk> <20171029014528.d1d1ab810ecb1c3bbe02b835@gentoo.org> From: Wols Lists X-Enigmail-Draft-Status: N1010 Message-ID: <59F51C5B.40609@youngman.org.uk> Date: Sun, 29 Oct 2017 01:10:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: <20171029014528.d1d1ab810ecb1c3bbe02b835@gentoo.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: 04ef6ecd-5477-4af4-9ff1-05a38a48c7e1 X-Archives-Hash: e075ab7bcdbcf4a7b4b2407ac7d24d69 On 28/10/17 23:45, Andrew Savchenko wrote: >> emerge -u world >> > A will be emerged with options ... >> > B will be emerged with options ... >> > C will be emerged with options ... >> > D is blocked by E >> > F will be emerged with options ... >> > G is blocked by H >> > Giving up, too many circular dependencies >> > emerge A B C F > Ah, man, this is where your mistake is. You are assuming that it > is possible to get a correct dependency subgraph without building > full correct dependency graph first. This is not possible and this > is math. While the approach you described abode may work in some > practical cases, it will be busted in general case. > > The key moment here is that graph's root node may be changed during > dependency recalculation based on _how_ conflict is solved, the > same as all other nodes may be reordered. And dependencies which > appear to be valid before conflict is resolved may became invalid > after, consider the following dep tree: > > A > / \ > B C > | > !{D,E} > > - B and C depends on A; > - D conflicts with E and both depend on C; > > You assume that !{D,E} conflict can be skipped and A, B, C canbe > emerged. But let's assume that you selected D later, but D depends > on F and F conflicts with A[some_flag]. So you'll have to choose > some alternative to A or change its USE flags, this may require to > rebuild the whole dependency tree (and build order may change as > well). In order to prevent dozens (sometimes hundreds or even > thousands) of useless rebuilds and to avoid leaving intermediate > tree in the utterly broken state emerge fails if it can't build the > dependency graph. EXCEPT. My "emerge A B C F" will presumably then fail with those conflicts, and it will loop again and just do an "emerge A". I'm not saying "prune the graph first time, then just emerge everything". I'm saying "prune the graph, and try again with the reduced set". Thing is, I have always found that deleting blockers "emerge -C1", and emerging everything that I can get to emerge, is almost guaranteed to end up with a system where everything eventually emerges. The problem I have is that, if I delay updating (or something like kde with its gazillions of packages is upgraded), I end up with maybe 300 packages to be emerged. Trying to sort that mess out is a nightmare especially when emerge starts blowing up with circular dependencies and stuff, and old packages blocking new ones - "A version 2 is blocked by A version 1" etc etc. And all too often deleting the current version A (and the other packages - slated for replacement - that depend on A) fixes the problem. I think we're having a misunderstanding here. If emerge does what I'm asking for, and leaves the system in a broken state (as you seem to think it will), then that's a serious bug in emerge. You seem to think I'm asking emerge to prune the dependency tree - I'm not. I'm asking for it to prune the package list - if it can't sort out dependencies, drop that package from the package list and then, when it's got a list of packages that it thinks will work, go back to the start and try to emerge just those (calculating a new dependency tree). In other words, I'm asking emerge to automate what I do - look at the output, find a subset of packages that I think will work, and then ask it to try again with just those packages. I would be very surprised if it iterated repeatedly down to the null set. As for doing useless rebuilds, isn't that MY call, not yours? What is most valuable - my time, or my computer's time? As it stands, I have to babysit an emerge - calculating the full graph bombs, so I have to try to emerge a small subset, which might bomb, and when that works I try again with the full set that bombs, so I have to iterate again, ad nauseam ... I like to work on the principle "if the computer can automate what I do, then it should ..." What would you recommend as the best way (for somebody who's knowledge of gentoo is patchy) of dealing with the situation when an emerge blows up with loads of circular dependencies finishing with the message "too many errors, giving up"? As opposed to my way of "emerge what I can, then see what more emerges", which I have always found eventually fixes everything. Cheers, Wol