From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 4DD4413877A for ; Fri, 25 Jul 2014 02:03:24 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 168E2E1483; Fri, 25 Jul 2014 02:03:19 +0000 (UTC) Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 30BFBE147A for ; Fri, 25 Jul 2014 02:03:17 +0000 (UTC) Received: by mail-vc0-f172.google.com with SMTP id im17so6362160vcb.3 for ; Thu, 24 Jul 2014 19:03:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=PRYd65iu7CKNny5oOYKlKgLllv+hdp8Bkp4evPdRCdY=; b=bgfRxOws6J6w/wreNRWqXDPegughvW3th2NKuUQQfRhSlmeCAbKlQLkUgzsbZr+7Bz kutASA+NhCfq0Wh424M2L1qZ+6R8721gUziCEn2vDCby6jlHqKcE0oPsZWtn1f2cpFZL cfEunF3JeUQqqeffEG95LWMKwQqMDEjyI12DSw5jkhohzaDL8Ygu9dQGdVY+0npkgm0B ZvQgEApmTBx56Xi5xu6qo320KZJ6TObXAyffmYeDguJ4zpHDamSELMGhAmLlGNVkmnSV DUABWv/4zA+3vQWRQm5KbqUtAK2REUeiF1vKxezLUr+2qEOYCuiy3+LbZwZ2knVVXKku q45Q== 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 X-Received: by 10.52.239.6 with SMTP id vo6mr23676205vdc.59.1406078101391; Tue, 22 Jul 2014 18:15:01 -0700 (PDT) Sender: freemanrich@gmail.com Received: by 10.52.72.19 with HTTP; Tue, 22 Jul 2014 18:15:01 -0700 (PDT) In-Reply-To: References: <53CD6BED.10603@gentoo.org> <201407212153.04605.dilfridge@gentoo.org> <20140721205527.142cb3d5@googlemail.com> <1405976767.1013.9.camel@gentoo.org> <53CE6CED.1060300@gentoo.org> <21454.45733.912584.800633@a1i15.kph.uni-mainz.de> <21454.47827.725294.211687@a1i15.kph.uni-mainz.de> Date: Tue, 22 Jul 2014 21:15:01 -0400 X-Google-Sender-Auth: fqhefG98glQYJUw8z07JbnSBKIE Message-ID: Subject: Re: [gentoo-dev] Re: don't rely on dynamic deps From: Rich Freeman To: gentoo-dev Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: a7099260-df6b-4f20-ba50-48419da3c7f5 X-Archives-Hash: 13e76f5cdae7c64b294f0df157a70515 On Tue, Jul 22, 2014 at 4:06 PM, Martin Vaeth wrote: > ...but by introducing all the additional complications Ian > has mentioned. More precisely: What happens if new dependencies > are introduced which are not satisfied? > One has to face it: Portage must not just silently "update" the > database and thus silently produce a /var/db which does not > satisfy its own dependencies... While this is problematic, I think portage actually can handle this (but I haven't tested this recently). Portage already allows you to clean a package without its reverse deps leading to a system in exactly the state you describe. I believe portage will just try to bring the package back at the next emerge @world (or any other set containing the reverse dep). If there is a problem with the dependency version then the system is already broken anyway - portage just doesn't realize it. I think that allowing devs to instruct portage to update VDB with USE/dep/etc changes is potentially less problematic than having portage trying to guess what the right thing to do is. We could then either use that feature or revbump as appropriate under the specific circumstances. Ultimately I think the most important thing we need is for PMs to follow some kind of defined behavior. In our efforts to get portage to do the "right thing" we sometimes end up with a portage that does things that nobody really understands. Things like that tend to lead to convenience 95% of the time and head-banging the other 5%. I'm all for workarounds, but I'd advocate simple ones that lead to easily predicted behavior (and failure modes). I'd rather safely eliminate 70% of useless rebuilds than unsafely try to eliminate 90% of them. However, I do agree that we need to be sensitive to rebuilds. Rich