public inbox for gentoo-portage-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
@ 2013-11-21  9:21 Alexander Berntsen
  2013-11-21 11:19 ` [gentoo-portage-dev] " Duncan
                   ` (2 more replies)
  0 siblings, 3 replies; 12+ messages in thread
From: Alexander Berntsen @ 2013-11-21  9:21 UTC (permalink / raw
  To: gentoo-portage-dev

[-- Attachment #1: Type: text/plain, Size: 994 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

After talking to zmedico privately, and raising the issue and
discussing it with people in bug #481578[0], I implemented the
behaviour described in a comment[1] on said bug.

I sent this to zmedico almost two months ago, but it doesn't look like
he's coming back any time soon, so I'm sending it here and ask someone
to review and commit it (a role zmedico has typically played for me,
as well as being my "mentor" and guide and so on and so forth for
Portage hacking).

[0]  <https://bugs.gentoo.org/show_bug.cgi?id=481578>
[1]  <https://bugs.gentoo.org/show_bug.cgi?id=481578#c10>>
- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlKN0H0ACgkQRtClrXBQc7Vh/QD/WQRV+zK8Dgjmm2trFOG/tA1G
A3D5PjKWOz+r9uCvu+YBAJauUd/7KkiVyn6ozKfGKxJaRdqETGPbYaJc9rcXQc1b
=ZX2u
-----END PGP SIGNATURE-----

[-- Attachment #2: 0001-emerge-Deprecate-autounmask.patch --]
[-- Type: text/x-diff, Size: 5176 bytes --]

From 887d7c8e179f4f011047e42b547cf46261fb10c0 Mon Sep 17 00:00:00 2001
From: Alexander Berntsen <alexander@plaimi.net>
Date: Tue, 1 Oct 2013 11:40:55 +0200
Subject: [PATCH 1/3] emerge: Deprecate --autounmask

Remove the --autounmask option from emerge. Please note that removing
the option does not mean that the variable used for keeping track of
autounmasking is not removed from depgraph.py.
---
 man/emerge.1            | 33 ++++++++++-----------------------
 pym/_emerge/depgraph.py |  3 +--
 pym/_emerge/main.py     |  9 ---------
 3 files changed, 11 insertions(+), 34 deletions(-)

diff --git a/man/emerge.1 b/man/emerge.1
index c59185f..58bdc94 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -322,38 +322,25 @@ invalid input. This helps prevent accidental
 acceptance of the first choice. This option is
 intended to be set in the \fBmake.conf\fR(5)
 \fBEMERGE_DEFAULT_OPTS\fR variable.
-.TP
-.BR "\-\-autounmask [ y | n ]"
-Automatically unmask packages and generate package.use
-settings as necessary to satisfy dependencies. This
-option is enabled by default. If any configuration
-changes are required, then they will be displayed
-after the merge list and emerge will immediately
-abort. If the displayed configuration changes are
-satisfactory, you should copy and paste them into
-the specified configuration file(s), or enable the
 \fB\-\-autounmask\-write\fR option. The
 \fBEMERGE_DEFAULT_OPTS\fR variable may be used to
 disable this option by default in \fBmake.conf\fR(5).
 .TP
 .BR "\-\-autounmask\-unrestricted\-atoms [ y | n ]"
-If \-\-autounmask is enabled, keyword and mask changes
-using the \'=\' operator will be written. With this
-option, \'>=\' operators will be used whenever possible.
-USE and license changes always use the latter behavior.
+Keyword and mask changes using the \'=\' operator will be written. With this
+option, \'>=\' operators will be used whenever possible. USE and license
+changes always use the latter behavior.
 .TP
 .BR "\-\-autounmask\-keep\-masks [ y | n ]"
-If \-\-autounmask is enabled, no package.unmask or ** keyword changes
-will be created. This leads to unsatisfied dependencies if
-no other solution exists.
+No package.unmask or ** keyword changes will be created if this is activated.
+This leads to unsatisfied dependencies if no other solution exists.
 .TP
 .BR "\-\-autounmask\-write [ y | n ]"
-If \-\-autounmask is enabled, changes are written
-to config files, respecting \fBCONFIG_PROTECT\fR and \fB\-\-ask\fR.
-If the corresponding package.* is a file, the changes are appended to
-it, if it is a directory, changes are written to the lexicographically
-last file. This way it is always ensured that the new changes take
-precedence over existing changes.
+Write required unmask changes to the relevant config files, respecting
+\fBCONFIG_PROTECT\fR and \fB\-\-ask\fR. If the corresponding package.* is a
+file, the changes are appended to it, if it is a directory, changes are written
+to the lexicographically last file. This way it is always ensured that the new
+changes take precedence over existing changes.
 .TP
 .BR \-\-backtrack=COUNT
 Specifies an integer number of times to backtrack if
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 7b77edc..9fdfa43 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -427,7 +427,7 @@ class _dynamic_depgraph_config(object):
 		self._backtrack_infos = {}
 
 		self._buildpkgonly_deps_unsatisfied = False
-		self._autounmask = depgraph._frozen_config.myopts.get('--autounmask') != 'n'
+		self._autounmask = True
 		self._success_without_autounmask = False
 		self._traverse_ignored_deps = False
 		self._complete_mode = False
@@ -7971,7 +7971,6 @@ def _backtrack_depgraph(settings, trees, myopts, myparams, myaction, myfiles, sp
 				"\n\nautounmask breakage detected\n\n",
 				noiselevel=-1, level=logging.DEBUG)
 			mydepgraph.display_problems()
-		myopts["--autounmask"] = "n"
 		mydepgraph = depgraph(settings, trees, myopts, myparams, spinner,
 			frozen_config=frozen_config, allow_backtracking=False)
 		success, favorites = mydepgraph.select_files(myfiles)
diff --git a/pym/_emerge/main.py b/pym/_emerge/main.py
index 89413a9..fc73ef7 100644
--- a/pym/_emerge/main.py
+++ b/pym/_emerge/main.py
@@ -123,7 +123,6 @@ def insert_optional_args(args):
 
 	default_arg_opts = {
 		'--ask'                  : y_or_n,
-		'--autounmask'           : y_or_n,
 		'--autounmask-keep-masks': y_or_n,
 		'--autounmask-unrestricted-atoms' : y_or_n,
 		'--autounmask-write'     : y_or_n,
@@ -303,11 +302,6 @@ def parse_opts(tmpcmdline, silent=False):
 			"choices" : true_y_or_n
 		},
 
-		"--autounmask": {
-			"help"    : "automatically unmask packages",
-			"choices" : true_y_or_n
-		},
-
 		"--autounmask-unrestricted-atoms": {
 			"help"    : "write autounmask changes with >= atoms if possible",
 			"choices" : true_y_or_n
@@ -673,9 +667,6 @@ def parse_opts(tmpcmdline, silent=False):
 	else:
 		myoptions.ask = None
 
-	if myoptions.autounmask in true_y:
-		myoptions.autounmask = True
-
 	if myoptions.autounmask_unrestricted_atoms in true_y:
 		myoptions.autounmask_unrestricted_atoms = True
 
-- 
1.8.1.5


[-- Attachment #3: 0002-emerge-Rename-autounmask-write-to-autounmask.patch --]
[-- Type: text/x-diff, Size: 5538 bytes --]

From b425e5e375c4aa058e4b7efa41d15bd0487b6b12 Mon Sep 17 00:00:00 2001
From: Alexander Berntsen <alexander@plaimi.net>
Date: Tue, 1 Oct 2013 11:53:31 +0200
Subject: [PATCH 2/3] emerge: Rename --autounmask-write to --autounmask

Rename --autounmask-write to --autounmask. Please note that removing the
option does not mean that the variable used for keeping track of
autounmask writing is not removed from depgraph.py.
---
 man/emerge.1            | 19 +++++++++++--------
 pym/_emerge/depgraph.py |  4 ++--
 pym/_emerge/main.py     | 18 +++++++++---------
 3 files changed, 22 insertions(+), 19 deletions(-)

diff --git a/man/emerge.1 b/man/emerge.1
index 58bdc94..e23d1b4 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -322,10 +322,20 @@ invalid input. This helps prevent accidental
 acceptance of the first choice. This option is
 intended to be set in the \fBmake.conf\fR(5)
 \fBEMERGE_DEFAULT_OPTS\fR variable.
-\fB\-\-autounmask\-write\fR option. The
+\fB\-\-autounmask\fR option. The
 \fBEMERGE_DEFAULT_OPTS\fR variable may be used to
 disable this option by default in \fBmake.conf\fR(5).
 .TP
+.BR "\-\-autounmask [ y | n ]"
+Write required unmask changes to the relevant config files, respecting
+\fBCONFIG_PROTECT\fR. If invoked together with \fB\-\-ask\fR, emerge will
+prompt you to write the changes. If invoked along with \fB\-\-pretend\fR,
+emerge will merely output the required changes and not make any of them by
+itself. If the corresponding package.* is a file, the changes are appended to
+it, if it is a directory, changes are written to the lexicographically last
+file. This way it is always ensured that the new changes take precedence over
+existing changes.
+.TP
 .BR "\-\-autounmask\-unrestricted\-atoms [ y | n ]"
 Keyword and mask changes using the \'=\' operator will be written. With this
 option, \'>=\' operators will be used whenever possible. USE and license
@@ -335,13 +345,6 @@ changes always use the latter behavior.
 No package.unmask or ** keyword changes will be created if this is activated.
 This leads to unsatisfied dependencies if no other solution exists.
 .TP
-.BR "\-\-autounmask\-write [ y | n ]"
-Write required unmask changes to the relevant config files, respecting
-\fBCONFIG_PROTECT\fR and \fB\-\-ask\fR. If the corresponding package.* is a
-file, the changes are appended to it, if it is a directory, changes are written
-to the lexicographically last file. This way it is always ensured that the new
-changes take precedence over existing changes.
-.TP
 .BR \-\-backtrack=COUNT
 Specifies an integer number of times to backtrack if
 dependency calculation fails due to a conflict or an
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 9fdfa43..5b4b723 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -6806,7 +6806,7 @@ class depgraph(object):
 		(using CONFIG_PROTECT). The message includes the comments and the changes.
 		"""
 
-		autounmask_write = self._frozen_config.myopts.get("--autounmask-write", "n") == True
+		autounmask_write = self._frozen_config.myopts.get("--autounmask", "n") == True
 		autounmask_unrestricted_atoms = \
 			self._frozen_config.myopts.get("--autounmask-unrestricted-atoms", "n") == True
 		quiet = "--quiet" in self._frozen_config.myopts
@@ -7168,7 +7168,7 @@ class depgraph(object):
 				chk_updated_cfg_files(root,
 					[os.path.join(os.sep, USER_CONFIG_PATH)])
 		elif not pretend and not autounmask_write and roots:
-			writemsg("\nUse --autounmask-write to write changes to config files (honoring\n"
+			writemsg("\nUse --autounmask to write changes to config files (honoring\n"
 				"CONFIG_PROTECT). Carefully examine the list of proposed changes,\n"
 				"paying special attention to mask or keyword changes that may expose\n"
 				"experimental or unstable packages.\n",
diff --git a/pym/_emerge/main.py b/pym/_emerge/main.py
index fc73ef7..247317d 100644
--- a/pym/_emerge/main.py
+++ b/pym/_emerge/main.py
@@ -123,9 +123,9 @@ def insert_optional_args(args):
 
 	default_arg_opts = {
 		'--ask'                  : y_or_n,
+		'--autounmask'           : y_or_n,
 		'--autounmask-keep-masks': y_or_n,
 		'--autounmask-unrestricted-atoms' : y_or_n,
-		'--autounmask-write'     : y_or_n,
 		'--buildpkg'             : y_or_n,
 		'--complete-graph'       : y_or_n,
 		'--deep'       : valid_integers,
@@ -302,6 +302,11 @@ def parse_opts(tmpcmdline, silent=False):
 			"choices" : true_y_or_n
 		},
 
+		"--autounmask": {
+			"help"    : "automatically unmask packages",
+			"choices" : true_y_or_n
+		},
+
 		"--autounmask-unrestricted-atoms": {
 			"help"    : "write autounmask changes with >= atoms if possible",
 			"choices" : true_y_or_n
@@ -312,11 +317,6 @@ def parse_opts(tmpcmdline, silent=False):
 			"choices" : true_y_or_n
 		},
 
-		"--autounmask-write": {
-			"help"    : "write changes made by --autounmask to disk",
-			"choices" : true_y_or_n
-		},
-
 		"--accept-properties": {
 			"help":"temporarily override ACCEPT_PROPERTIES",
 			"action":"store"
@@ -667,15 +667,15 @@ def parse_opts(tmpcmdline, silent=False):
 	else:
 		myoptions.ask = None
 
+	if myoptions.autounmask in true_y:
+		myoptions.autounmask = True
+
 	if myoptions.autounmask_unrestricted_atoms in true_y:
 		myoptions.autounmask_unrestricted_atoms = True
 
 	if myoptions.autounmask_keep_masks in true_y:
 		myoptions.autounmask_keep_masks = True
 
-	if myoptions.autounmask_write in true_y:
-		myoptions.autounmask_write = True
-
 	if myoptions.buildpkg in true_y:
 		myoptions.buildpkg = True
 
-- 
1.8.1.5


[-- Attachment #4: 0003-emerge-Make-autounmask-y-if-ask-y.patch --]
[-- Type: text/x-diff, Size: 2451 bytes --]

From 9c03d52526f58eb53c9e76785352fbb53413898d Mon Sep 17 00:00:00 2001
From: Alexander Berntsen <alexander@plaimi.net>
Date: Tue, 1 Oct 2013 12:10:14 +0200
Subject: [PATCH 3/3] emerge: Make --autounmask=y if --ask=y

---
 man/emerge.1            | 9 +++++----
 pym/_emerge/depgraph.py | 5 +++--
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/man/emerge.1 b/man/emerge.1
index e23d1b4..52f8ed7 100644
--- a/man/emerge.1
+++ b/man/emerge.1
@@ -331,10 +331,11 @@ Write required unmask changes to the relevant config files, respecting
 \fBCONFIG_PROTECT\fR. If invoked together with \fB\-\-ask\fR, emerge will
 prompt you to write the changes. If invoked along with \fB\-\-pretend\fR,
 emerge will merely output the required changes and not make any of them by
-itself. If the corresponding package.* is a file, the changes are appended to
-it, if it is a directory, changes are written to the lexicographically last
-file. This way it is always ensured that the new changes take precedence over
-existing changes.
+itself. This option is enabled by default if are running emerge with
+\fB\-\-ask\fR or \fB\-\-pretend\fR, and disabled by default elsewise. If the
+corresponding package.* is a file, the changes are appended to it, if it is a
+directory, changes are written to the lexicographically last file. This way it
+is always ensured that the new changes take precedence over existing changes.
 .TP
 .BR "\-\-autounmask\-unrestricted\-atoms [ y | n ]"
 Keyword and mask changes using the \'=\' operator will be written. With this
diff --git a/pym/_emerge/depgraph.py b/pym/_emerge/depgraph.py
index 5b4b723..e8b680d 100644
--- a/pym/_emerge/depgraph.py
+++ b/pym/_emerge/depgraph.py
@@ -6806,12 +6806,13 @@ class depgraph(object):
 		(using CONFIG_PROTECT). The message includes the comments and the changes.
 		"""
 
-		autounmask_write = self._frozen_config.myopts.get("--autounmask", "n") == True
+		ask = "--ask" in self._frozen_config.myopts
+		autounmask_write = ask or \
+				self._frozen_config.myopts.get("--autounmask", "n") == True
 		autounmask_unrestricted_atoms = \
 			self._frozen_config.myopts.get("--autounmask-unrestricted-atoms", "n") == True
 		quiet = "--quiet" in self._frozen_config.myopts
 		pretend = "--pretend" in self._frozen_config.myopts
-		ask = "--ask" in self._frozen_config.myopts
 		enter_invalid = '--ask-enter-invalid' in self._frozen_config.myopts
 
 		def check_if_latest(pkg):
-- 
1.8.1.5


^ permalink raw reply related	[flat|nested] 12+ messages in thread

* [gentoo-portage-dev] Re: [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
  2013-11-21  9:21 [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask Alexander Berntsen
@ 2013-11-21 11:19 ` Duncan
  2013-11-21 12:03   ` Alexander Berntsen
  2013-11-21 16:30 ` [gentoo-portage-dev] " 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
  2 siblings, 1 reply; 12+ messages in thread
From: Duncan @ 2013-11-21 11:19 UTC (permalink / raw
  To: gentoo-portage-dev

Alexander Berntsen posted on Thu, 21 Nov 2013 10:21:02 +0100 as excerpted:

> After talking to zmedico privately, and raising the issue and discussing
> it with people in bug #481578[0], I implemented the behaviour described
> in a comment[1] on said bug.
> 
> I sent this to zmedico almost two months ago, but it doesn't look like
> he's coming back any time soon, so I'm sending it here and ask someone
> to review and commit it (a role zmedico has typically played for me, as
> well as being my "mentor" and guide and so on and so forth for Portage
> hacking).
> 
> [0]  <https://bugs.gentoo.org/show_bug.cgi?id=481578>
> [1]  <https://bugs.gentoo.org/show_bug.cgi?id=481578#c10>>

I'm with zmedico in comment #11, and *STRONGLY* oppose this change as 
you're proposing.  Current autounmask is **NOT** useless.

FWIW, I have a very specific portage layout and there's no way "dumb 
automation" could put what I'd consider the appropriate write in what I'd 
consider the appropriate file, nor do I want it to try!  (And even if it 
could do it perfectly, I want to /know/ what my config is, and the best 
way for me to /know/ my config is if the only way it changes is if I 
change it myself!)

OTOH, current default autounmask (without write) behavior, having portage 
tell me what (it thinks) I need to unmask and/or what package.use flags 
it thinks I need is fine, and often quite helpful indeed, as long as it's 
not actually trying to actually WRITE it anywhere!

If I read the above correctly, what you're proposing would kill that 
behavior entirely if --ask is used, defaulting to writing (fine if it can 
be turned off), with no way (at least no way with --ask instead of
--pretend) to tell portage to make the suggestion it with --autounmask 
(which is the default now), with absolutely no chance it's going to 
attempt to actually rewrite my config on its own, period.

OTOH, Zac's suggestion, to simply enable autounmask-write by default but 
allow the user to set --autounmask-write=n if they want, would be just 
fine, since I could put that in default options and be done with it.

Tho even that's a sufficiently drastic change from current behavior that 
I'd expect a good changelog entry mentioning it, and preferably a news 
item, as it has the potential to screw up people's configs if they aren't 
paying attention when the default changes.

-- 
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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-portage-dev] Re: [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
  2013-11-21 11:19 ` [gentoo-portage-dev] " Duncan
@ 2013-11-21 12:03   ` Alexander Berntsen
  2013-11-21 13:34     ` Duncan
  0 siblings, 1 reply; 12+ messages in thread
From: Alexander Berntsen @ 2013-11-21 12:03 UTC (permalink / raw
  To: gentoo-portage-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/11/13 12:19, Duncan wrote:
> I'm with zmedico in comment #11, and *STRONGLY* oppose this change 
> as you're proposing.  Current autounmask is **NOT** useless.
How is it not? Consider comment 6[0] and 10[1].

> FWIW, I have a very specific portage layout and there's no way
> "dumb automation" could put what I'd consider the appropriate write
> in what I'd consider the appropriate file, nor do I want it to try!
> (And even if it could do it perfectly, I want to /know/ what my
> config is, and the best way for me to /know/ my config is if the
> only way it changes is if I change it myself!)
Irrelevant.

> OTOH, current default autounmask (without write) behavior, having 
> portage tell me what (it thinks) I need to unmask and/or what 
> package.use flags it thinks I need is fine, and often quite helpful
>  indeed, as long as it's not actually trying to actually WRITE it 
> anywhere!
Irrelevant.

> If I read the above correctly, what you're proposing would kill
> that behavior entirely if --ask is used, defaulting to writing
> (fine if it can be turned off), with no way (at least no way with
> --ask instead of --pretend) to tell portage to make the suggestion
> it with --autounmask (which is the default now), with absolutely no
> chance it's going to attempt to actually rewrite my config on its
> own, period.
I don't understand this sentence, but I think you *don't* understand
what I am saying. Please read comment 10[1], in which I present examples.

> OTOH, Zac's suggestion, to simply enable autounmask-write by
> default but allow the user to set --autounmask-write=n if they
> want, would be just fine, since I could put that in default options
> and be done with it.
Enabling --autounmask-write by default is a terrible idea. It will
result in a lot of spam. Furthermore, consider comment 13[2].

> Tho even that's a sufficiently drastic change from current behavior
>  that I'd expect a good changelog entry mentioning it, and
> preferably a news item, as it has the potential to screw up
> people's configs if they aren't paying attention when the default
> changes.
I agree that a news item could be useful.

[0]  <https://bugs.gentoo.org/show_bug.cgi?id=481578#c6>
[1]  <https://bugs.gentoo.org/show_bug.cgi?id=481578#c10>
[2]  <https://bugs.gentoo.org/show_bug.cgi?id=481578#c13>
- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlKN9pgACgkQRtClrXBQc7UvcgD/XRz/iHDsnFa+qt8Q8ms+K//D
wD/DIAWlKPStlEKW8noA/0b3aj5+jRGmebq1q4lnkp5PaweShxzvyphP2ZeRe5up
=btNb
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [gentoo-portage-dev] Re: [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
  2013-11-21 12:03   ` Alexander Berntsen
@ 2013-11-21 13:34     ` Duncan
  2013-11-21 14:23       ` Alexander Berntsen
  0 siblings, 1 reply; 12+ messages in thread
From: Duncan @ 2013-11-21 13:34 UTC (permalink / raw
  To: gentoo-portage-dev

Alexander Berntsen posted on Thu, 21 Nov 2013 13:03:36 +0100 as excerpted:

> On 21/11/13 12:19, Duncan wrote:
>> I'm with zmedico in comment #11, and *STRONGLY* oppose this change as
>> you're proposing.  Current autounmask is **NOT** useless.
> How is it not? Consider comment 6[0] and 10[1].

I read comment 10, and am objecting based on it, because there'd be no 
way to do what I'm doing currently and which my workflow depends on, 
which you call irrelevant (below).

>> FWIW, I have a very specific portage layout and there's no way "dumb
>> automation" could put what I'd consider the appropriate write in what
>> I'd consider the appropriate file, nor do I want it to try!
>> (And even if it could do it perfectly, I want to /know/ what my config
>> is, and the best way for me to /know/ my config is if the only way it
>> changes is if I change it myself!)
> Irrelevant.
> 
>> OTOH, current default autounmask (without write) behavior, having
>> portage tell me what (it thinks) I need to unmask and/or what
>> package.use flags it thinks I need is fine, and often quite helpful
>>  indeed, as long as it's not actually trying to actually WRITE it
>> anywhere!
> Irrelevant.
> 
>> If I read the above correctly, what you're proposing would kill that
>> behavior entirely if --ask is used, defaulting to writing (fine if it
>> can be turned off), with no way (at least no way with --ask instead of
>> --pretend) to tell portage to make the suggestion it with --autounmask
>> (which is the default now), with absolutely no chance it's going to
>> attempt to actually rewrite my config on its own, period.
> I don't understand this sentence, but I think you *don't* understand
> what I am saying. Please read comment 10[1], in which I present
> examples.

1) Because the dependency calculations take time, I normally use --ask so 
I don't have to have portage redo those calculations if I like what its 
telling me it's going to do.

2) Under no circumstances do I want portage rewriting masks, etc, on its 
own, not even with config-protect.

3) Despite that, I find the suggestions it makes saying what it /thinks/ 
it needs unmasked useful -- I just want to write them to the file I want, 
with the comment I want (sometimes with a bit different atom, too), which 
portage wouldn't do.

4) You're saying emerge --ask foo would write the config, and I don't see 
any way to turn that off without also turning off portage's suggestion 
generation as currently controlled by --autounmask (which is on by 
default), or without switching --ask to --pretend.  Your proposal is 
broken behavior as far as I'm concerned, because I find portage's 
suggestions (current autounmask) useful, not the entirely useless you 
seem to think they are without automatically writing them, which I do NOT 
want portage to do under /any/ circumstances.

5) There needs to be a way to get portage's current emerge --ask
--autounmask foo (without --autounmask-write) behavior, because that's 
/exactly/ what I use and find most useful.  But I don't particularly care 
what the default is since I can configure it as needed, as long as this 
current behavior remains possible.

>> OTOH, Zac's suggestion, to simply enable autounmask-write by default
>> but allow the user to set --autounmask-write=n if they want, would be
>> just fine, since I could put that in default options and be done with
>> it.
> Enabling --autounmask-write by default is a terrible idea. It will
> result in a lot of spam. Furthermore, consider comment 13[2].

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?

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

-- 
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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-portage-dev] Re: [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
  2013-11-21 13:34     ` Duncan
@ 2013-11-21 14:23       ` Alexander Berntsen
  2013-11-22  5:37         ` Duncan
  0 siblings, 1 reply; 12+ messages in thread
From: Alexander Berntsen @ 2013-11-21 14:23 UTC (permalink / raw
  To: gentoo-portage-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/11/13 14:34, Duncan wrote:
> I read comment 10, and am objecting based on it
You have fundamentally misunderstood everything in it. Please reread it.

> 1) Because the dependency calculations take time, I normally use 
> --ask so I don't have to have portage redo those calculations if I
>  like what its telling me it's going to do.
> 
> 2) Under no circumstances do I want portage rewriting masks, etc,
> on its own, not even with config-protect.
> 
> 3) Despite that, I find the suggestions it makes saying what it 
> /thinks/ it needs unmasked useful -- I just want to write them to 
> the file I want, with the comment I want (sometimes with a bit 
> different atom, too), which portage wouldn't do.
All of this is irrelevant to my patches.

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

> 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].


[0]  <https://bugs.gentoo.org/show_bug.cgi?id=481578#c10>
- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlKOF3YACgkQRtClrXBQc7XcYgD/bW0XXYgXwkA7CvtFVCphboxd
MQNdi8HTZ3SCP8N+mRIBAIEhlHJsmtLqhreJNNWc+0KeSOR0IaOoXz0J16kAjF8c
=Te1c
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
  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 16:30 ` Paul Varner
  2013-11-21 16:46   ` Alexander Berntsen
  2013-11-21 20:06 ` Zac's status (Was: Re: [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask) Pacho Ramos
  2 siblings, 1 reply; 12+ messages in thread
From: Paul Varner @ 2013-11-21 16:30 UTC (permalink / raw
  To: gentoo-portage-dev

On 11/21/13 03:21, Alexander Berntsen wrote:
> After talking to zmedico privately, and raising the issue and
> discussing it with people in bug #481578[0], I implemented the
> behaviour described in a comment[1] on said bug.
>
> I sent this to zmedico almost two months ago, but it doesn't look like
> he's coming back any time soon, so I'm sending it here and ask someone
> to review and commit it (a role zmedico has typically played for me,
> as well as being my "mentor" and guide and so on and so forth for
> Portage hacking).
>
> [0]  <https://bugs.gentoo.org/show_bug.cgi?id=481578>
> [1]  <https://bugs.gentoo.org/show_bug.cgi?id=481578#c10>>

I turn off autounmask because I don't find it useful.  I have found too
many times when it wants me to unmask something that really doesn't need
to be unmasked.

It is not clear to me from the patches if I can still do that.

Regards,
Paul


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
  2013-11-21 16:30 ` [gentoo-portage-dev] " Paul Varner
@ 2013-11-21 16:46   ` Alexander Berntsen
  2013-11-21 21:05     ` Paul Varner
  0 siblings, 1 reply; 12+ messages in thread
From: Alexander Berntsen @ 2013-11-21 16:46 UTC (permalink / raw
  To: gentoo-portage-dev

[-- Attachment #1: Type: text/plain, Size: 864 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/11/13 17:30, Paul Varner wrote:
> I turn off autounmask because I don't find it useful.  I have
> found too many times when it wants me to unmask something that
> really doesn't need to be unmasked.
> 
> It is not clear to me from the patches if I can still do that.
I don't understand your predicament. --autounmask per today just
prints out necessary keyword changes. If you run without --autounmask
it doesn't print them. I attached an example.
- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlKOOOMACgkQRtClrXBQc7VH7wD/dwNppvZmNjonrg9o9xD2rDl5
K5BKd1nPBHpb9yhCI18A/0XEpZanBpvscHchsDfo3sZlhaU48vGAseJk1P/AOswC
=QWOy
-----END PGP SIGNATURE-----

[-- Attachment #2: example.txt --]
[-- Type: text/plain, Size: 2652 bytes --]

$ sudo emerge -av =www-client/firefox-24.1.1

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ~] dev-libs/nspr-4.10.2 [4.10] USE="-debug" 1,078 kB
[ebuild     U ~] dev-libs/nss-3.15.3 [3.15.2] USE="-utils" 6,142 kB
[ebuild     U ~] www-client/firefox-24.1.1 [17.0.9] USE="alsa bindist dbus jit libnotify minimal -custom-cflags -custom-optimization -debug -gstreamer (-pgo) -pulseaudio% (-selinux) -startup-notification -system-cairo% -system-icu% -system-jpeg% -system-sqlite -wifi" LINGUAS="-af -ak -ar -as -ast -be -bg -bn_BD -bn_IN -br -bs -ca -cs -csb -cy -da -de -el -en_GB -en_ZA -eo -es_AR -es_CL -es_ES -es_MX -et -eu -fa -fi -fr -fy_NL -ga_IE -gd -gl -gu_IN -he -hi_IN -hr -hu -hy_AM -id -is -it -ja -kk -km -kn -ko -ku -lg -lt -lv -mai -mk -ml -mr -nb_NO -nl -nn_NO -nso -or -pa_IN -pl -pt_BR -pt_PT -rm -ro -ru -si -sk -sl -son -sq -sr -sv_SE -ta -ta_LK -te -th -tr -uk -vi -zh_CN -zh_TW -zu" 117,062 kB

Total: 3 packages (3 upgrades), Size of downloads: 124,281 kB

The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
# required by www-client/firefox-24.1.1
# required by @selected
# required by @world (argument)
=dev-libs/nspr-4.10.2 ~amd64
# required by =www-client/firefox-24.1.1 (argument)
=www-client/firefox-24.1.1 ~amd64
# required by www-client/firefox-24.1.1
# required by @selected
# required by @world (argument)
=dev-libs/nss-3.15.3 ~amd64

Use --autounmask-write to write changes to config files (honoring
CONFIG_PROTECT). Carefully examine the list of proposed changes,
paying special attention to mask or keyword changes that may expose
experimental or unstable packages.





$ sudo emerge -av =www-client/firefox-24.1.1 --autounmask=n
!!! Repository 'my_local_overlay' is missing masters attribute in '/home/alexander/gentoo/local_portage/metadata/layout.conf'
!!! Set 'masters = gentoo' in this file for future compatibility
!!! Repository 'games' is missing masters attribute in '/var/lib/layman/games/metadata/layout.conf'
!!! Set 'masters = gentoo' in this file for future compatibility

 * IMPORTANT: 4 news items need reading for repository 'gentoo'.
 * Use eselect news to read news items.


These are the packages that would be merged, in order:

Calculating dependencies... done!

!!! All ebuilds that could satisfy "=www-client/firefox-24.1.1" have been masked.
!!! One of the following masked packages is required to complete your request:
- www-client/firefox-24.1.1::gentoo (masked by: ~amd64 keyword)

For more information, see the MASKED PACKAGES section in the emerge

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Zac's status (Was: Re: [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask)
  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 16:30 ` [gentoo-portage-dev] " Paul Varner
@ 2013-11-21 20:06 ` Pacho Ramos
  2013-11-22  8:51   ` Alexander Berntsen
  2 siblings, 1 reply; 12+ messages in thread
From: Pacho Ramos @ 2013-11-21 20:06 UTC (permalink / raw
  To: gentoo-portage-dev

El jue, 21-11-2013 a las 10:21 +0100, Alexander Berntsen escribió:
> I sent this to zmedico almost two months ago, but it doesn't look like
> he's coming back any time soon, so I'm sending it here and ask someone
> to review and commit it (a role zmedico has typically played for me,
> as well as being my "mentor" and guide and so on and so forth for
> Portage hacking).
> 
> [0]  <https://bugs.gentoo.org/show_bug.cgi?id=481578>
> [1]  <https://bugs.gentoo.org/show_bug.cgi?id=481578#c10>>

Does anyone know what did occur to Zac? I expect it's not a major
problem or similar :'(



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
  2013-11-21 16:46   ` Alexander Berntsen
@ 2013-11-21 21:05     ` Paul Varner
  0 siblings, 0 replies; 12+ messages in thread
From: Paul Varner @ 2013-11-21 21:05 UTC (permalink / raw
  To: gentoo-portage-dev

On 11/21/13 10:46, Alexander Berntsen wrote:
> I don't understand your predicament. --autounmask per today just
> prints out necessary keyword changes. If you run without --autounmask
> it doesn't print them. I attached an example.
 You answered my question with the example.  Thank you.

Regards,
Paul


^ permalink raw reply	[flat|nested] 12+ messages in thread

* [gentoo-portage-dev] Re: [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
  2013-11-21 14:23       ` Alexander Berntsen
@ 2013-11-22  5:37         ` Duncan
  2013-11-22  8:29           ` Alexander Berntsen
  0 siblings, 1 reply; 12+ messages in thread
From: Duncan @ 2013-11-22  5:37 UTC (permalink / raw
  To: gentoo-portage-dev

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



^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: [gentoo-portage-dev] Re: [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask
  2013-11-22  5:37         ` Duncan
@ 2013-11-22  8:29           ` Alexander Berntsen
  0 siblings, 0 replies; 12+ messages in thread
From: Alexander Berntsen @ 2013-11-22  8:29 UTC (permalink / raw
  To: gentoo-portage-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 22/11/13 06:37, Duncan wrote:
> 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.
You don't understand what this does. Please try it.
> 
> 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.
It doesn't.

> 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.
You don't understand how --autounmask and --autounmask-write works, or
I don't understand what you mean. Please try

=www-client/firefox-24.1.1 --autounmask=y --ask
# Assuming you are on a stable system, if not, try another package.

- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlKPFdgACgkQRtClrXBQc7XSjQD9EfBS9cZ03UMoXYgp34oXUuPy
52w+qnyR3ruRd6FevrsBAK7imsn07qL0FeQbSJZAVoLXafauFPoiRJsoUBlZAIpQ
=jziW
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: Zac's status (Was: Re: [gentoo-portage-dev] [PATCHES] Remove --autounmask, rename --autounmask-write to --autounmask)
  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
  0 siblings, 0 replies; 12+ messages in thread
From: Alexander Berntsen @ 2013-11-22  8:51 UTC (permalink / raw
  To: gentoo-portage-dev

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 21/11/13 21:06, Pacho Ramos wrote:
> Does anyone know what did occur to Zac? I expect it's not a major 
> problem or similar :'(
Someone posted in #gentoo-portage that they had spoken to him, and that
he was just taking a break. (I don't remember who made this post.)

His devaway is «limited availability; please feel free to maintain
"my" packages @ 2013/11/13 12:19Z».
- -- 
Alexander
alexander@plaimi.net
http://plaimi.net/~alexander
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlKPGyEACgkQRtClrXBQc7VBGwD9F38OqWmnQscOIF3HrkiUyCE9
4U/T+/JX6SgVCeTj72oA/01xGCN3EDgudtA42BE9K05cRtbNGbQxS08TLj40cDqi
=vFXH
-----END PGP SIGNATURE-----


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2013-11-22  8:51 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
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
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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox