|Summary:||sys-app/portage-2.2 --autounmask behavior (automatically edit config)|
|Product:||Portage Development||Reporter:||Domen Kožar <domen>|
|Component:||Enhancement/Feature Requests||Assignee:||Portage team <dev-portage>|
|Severity:||enhancement||CC:||esigra, jlec, pacho, tommy|
|Package list:||Runtime testing required:||---|
|Bug Depends on:||280097|
|Bug Blocks:||300071, 358927|
Description Domen Kožar 2010-11-16 16:47:57 UTC
By current behavior when passing --autounmask to portage, it only spits out lines that should be pasted to package.* family. I think this is not auto enough, we could improve the process even better. Problem with current implementation: * you cannot redirect output to /etc/portage/package.keywords for example, since portage prints other garbage that doesn't belong there * it does not obey --pretend flag My suggestion to make it automatic is: 1. if --pretend is not passed, populate package.* family automatically and start emerging the package 2. if --pretend is passed, ask for confirmation before doing 1. Reproducible: Always
Comment 1 Zac Medico 2010-11-22 01:47:46 UTC
It's worth noting that bug 258371 would produce a similar effect (though only for USE dependencies).
Comment 2 Denis Lisov 2011-02-25 09:08:10 UTC
(In reply to comment #0) > My suggestion to make it automatic is: > > 1. if --pretend is not passed, populate package.* family automatically and > start emerging the package > 2. if --pretend is passed, ask for confirmation before doing 1. The "ask for confirmation" seems to be the behaviour intended for --ask, not --pretend.
Comment 3 James Broadhead 2011-03-06 15:41:33 UTC
(In reply to comment #2) > (In reply to comment #0) > > 1. if --pretend is not passed, populate package.* family automatically and > > start emerging the package > > 2. if --pretend is passed, ask for confirmation before doing 1. > The "ask for confirmation" seems to be the behaviour intended for --ask, not > --pretend. I concur; 1. emerge --autounmask foo => package.* populated, emerge proceeds. 2. emerge -p --autounmask foo => print the changes that would be made to package.*, print the packages that would be emerged 3. emerge -a --autounmask foo => As 2, with "Are you sure?", then as 1.
Comment 4 Zac Medico 2011-05-15 20:12:37 UTC
Comment 5 Domen Kožar 2011-05-15 22:22:14 UTC
Why reinvent the wheel with --autounmask-write, if we have standardized --ask parameter? It feels so much intuitive to use global flag to handle logical situations like ask the user for confirmation or just do it. Using only --autounmask to output what needs to be process further and can be totally automatized feels rather redundant to me. Also, --verbose can output the changes needed to be modified in /etc/portage/ if the user want's to know about that. I'm totally thinking from UX perspective and want to double check decision about that. Other than that, this change really made my rainy day. Portage is becoming an masterpiece of package management.
Comment 6 Zac Medico 2011-05-15 22:40:24 UTC
(In reply to comment #5) > Why reinvent the wheel with --autounmask-write, if we have standardized --ask > parameter? It's more flexible to use separate options whenever the things that they control are separable. However, I think we should modify the --autounmask-write behavior to respect the --ask option and prompt the user before making the changes.
Comment 7 Zac Medico 2011-05-15 22:41:31 UTC
Also, note that you can set EMERGE_DEFAULT_OPTS="--autounmask-write" if you want it enabled by default.
Comment 8 Zac Medico 2011-05-17 01:16:48 UTC
Support for --ask is in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=1c16fe8e3740e6b9e1e1562731a0c4b5a000fd92
Comment 9 Domen Kožar 2011-05-17 10:14:05 UTC
Thanks! I'll try the changes today and confirm the feature :)
Comment 10 Zac Medico 2011-05-18 06:05:34 UTC
This is released in 2.2.0_alpha34. However, I'll leave this bug open until it's released in an umasked version. I plan to release portage-2.1.10 with this feature in approximately 3 weeks.
Comment 11 Zac Medico 2011-06-06 13:07:10 UTC
This is fixed in 2.1.10