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 5F85213877A for ; Wed, 13 Aug 2014 19:24:26 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EB905E0C35; Wed, 13 Aug 2014 19:24:23 +0000 (UTC) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 6713CE0C2E for ; Wed, 13 Aug 2014 19:24:23 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id l13so11273909iga.16 for ; Wed, 13 Aug 2014 12:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=Kvsz3gVHgREPxyf0SZvMHzBhG2sGyMI9f1tjj8qgMiE=; b=0KCEXK7ub7J4+wsXQAf/ExWPPzQFIwmLoCHTpYvuXf/gMD9ZaWT/IYNIbUD0B0xsgD oHdueG0GW0avtMYjiSfKLTAlqbKocX4Fi2NQEyRWqamDnpEFPRxqdPFEeqYdR8uB+KFB WnqaFmsbhKez126Br3vjO/86DCqLbxjxRDQnMq+Li9qvBmaJmc4OVfA6eMwkD32w+5SA tARJ0hK33K+HbllEIIFYqy/h4I86JIz1VLfR8RtPB/E4muM87Cp3ukuIPLB+vg85a3Zv XbxN4HlhqGQeijBLu6U52kJgrdbtwYJK7ziSmSZ/53mzWR8jVC9cTQmh1jMuEKBymIOm 99jg== X-Received: by 10.50.136.167 with SMTP id qb7mr10631636igb.31.1407957862681; Wed, 13 Aug 2014 12:24:22 -0700 (PDT) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-portage-dev@lists.gentoo.org Reply-to: gentoo-portage-dev@lists.gentoo.org MIME-Version: 1.0 Received: by 10.50.30.198 with HTTP; Wed, 13 Aug 2014 12:24:02 -0700 (PDT) In-Reply-To: References: <1407836235-13528-1-git-send-email-bernalex@gentoo.org> <53EB8D23.20208@gentoo.org> <20140813094532.6ba40f8f.dolsen@gentoo.org> <53EB98BC.4050404@gentoo.org> From: Wyatt Epp Date: Wed, 13 Aug 2014 15:24:02 -0400 Message-ID: Subject: Re: [gentoo-portage-dev] Re: [PATCH 0/4] Autounmask changes To: gentoo-portage-dev@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: b16a477f-4f82-4ffc-81aa-5a2862de7909 X-Archives-Hash: 5e7ff1f0e52afbd4406a494636c43a13 On Wed, Aug 13, 2014 at 1:59 PM, Duncan <1i5t5.duncan@cox.net> wrote: > Alexander Berntsen posted on Wed, 13 Aug 2014 18:56:28 +0200 as excerpted: >> >> emerge foo # this will do what --autounmask does today >> emerge foo --autounmask # this will do what --autounmask-write does >> emerge foo -a # this will do what --ask --autounmask-write does >> emerge foo --autounmask=n # this will do what --autounmask=n does >> >> The problem here is that there is no way to do e.g. emerge foo --ask, >> and get suggestions any longer. You can either have it prompt to write >> stuff, or you can have it not do anything -- but you can't explicitly >> have it suggest stuff without prompting to write. This is bad design. >> Is there really any situation where the user would benefit from not having the suggestions? That's sort of rhetorical because it's on by default, but the point is more that Portage already takes a rather proactive stance with regard to informing the user about the details of slot and version conflicts; what's a few more lines? (And if that IS, indeed, a problem, there's always --quiet.) Regardless of that, writing keywords as a side-effect of --ask is not a good path. My personal suggestion would instead be that --autounmask only do exactly what it says: automatically resolve minimum keywords needed to merge the depgraph and put them where they need to be. When used in conjunction with --ask, it would then tell you "These atoms will be appended to package.keywords" or whatever file it chooses. Unfortunately historical baggage may prevent that, but it's a nice thought. > * I don't want portage writing mask/use changes on its own under any > circumstances, as I use directories and have my own idea of what files I > want stuff in. > I have this same issue as I give every category its own file. Can we generalise this in such a way that finer-grained control over write location could be added? (Off the top of my head, I'm imagining passing the atom through something like a FILE_REGEX or maybe an optional script parameter, and the output is the filename within package.keywords/) -Wyatt