public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Duncan <1i5t5.duncan@cox.net>
To: gentoo-portage-dev@lists.gentoo.org
Subject: [gentoo-portage-dev] Re: [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
Date: Fri, 22 Nov 2013 05:37:25 +0000 (UTC)	[thread overview]
Message-ID: <pan$e4dbc$26d1e5f7$40d99c24$47d12391@cox.net> (raw)
In-Reply-To: 528E1776.1030908@plaimi.net

Alexander Berntsen posted on Thu, 21 Nov 2013 15:23:50 +0100 as excerpted:

>> 4) You're saying emerge --ask foo would write the config
> No. Please read comment 10[0].

Quoting one example from comment 10:

emerge --ask foo
would also do what is currently done by: emerge --ask --autounmask-write 
foo

Which is exactly what I said, and what you're now saying it won't do, 
while pointing at comment 10 which says exactly the opposite.

It's that change in behavior based on comment 10 that I'm most 
protesting, since I depend on being able to tell portage to go ahead with 
the merges if they look good (thus the --ask), but under *NO* 
circumstances do I want it writing its changes to the various use/mask 
files.

>> 5) There needs to be a way to get portage's current emerge --ask
>> --autounmask foo (without --autounmask-write)
> There is. This doesn't change in my patches. Please read the code or
> comment 10[0].
> 
>> I'd tend to agree, but in that case, why are you wanting to do away
>>  with the ability to have portage spit out its opinion, without
>> having portage actually do the write, while using --ask?
> Because it can be done without --ask. See comment 10[0].

The only way you propose to do that in comment 10 is with --pretend, 
which would be a seriously negative change in behavior for my use-case, 
since it would require having portage recalculate the dependencies it's 
just calculated with the --pretend, without it.  --ask currently avoids 
that situation, since when I'm happy with the output, I can simply let it 
go ahead.


> [0]  <https://bugs.gentoo.org/show_bug.cgi?id=481578#c10>



-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman



  reply	other threads:[~2013-11-22  5:38 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-11-21  9:21 [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask Alexander Berntsen
2013-11-21 11:19 ` [gentoo-portage-dev] " Duncan
2013-11-21 12:03   ` Alexander Berntsen
2013-11-21 13:34     ` Duncan
2013-11-21 14:23       ` Alexander Berntsen
2013-11-22  5:37         ` Duncan [this message]
2013-11-22  8:29           ` Alexander Berntsen
2013-11-21 16:30 ` [gentoo-portage-dev] " Paul Varner
2013-11-21 16:46   ` Alexander Berntsen
2013-11-21 21:05     ` Paul Varner
2013-11-21 20:06 ` Zac's status (Was: Re: [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask) Pacho Ramos
2013-11-22  8:51   ` Alexander Berntsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='pan$e4dbc$26d1e5f7$40d99c24$47d12391@cox.net' \
    --to=1i5t5.duncan@cox.net \
    --cc=gentoo-portage-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox