The job of autounmask can be done more efficiently if portage implements it.
*** Bug 319871 has been marked as a duplicate of this bug. ***
Note, you might like to have a look at Bug 319871 for more ideas.
Now we have support for unmasking of packages with unstable keywords, in these commits and everything in between: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=320a9800e157756f79f1774654774cc460ada5b1 http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=03a201256ab9a8557862e30732ecc9b7de19a885 It's triggered by the --autounmask option. We may enable it by default eventually, but for now I want it disabled by default in order to minimize the impact of bugs.
I really don't think setting it to default is a good idea... At least I wont like it.
(In reply to comment #4) > I really don't think setting it to default is a good idea... At least I wont > like it. > Note that unlike app-portage/autounmask doesn't modify the configuration files, but outputs the changes in a way that it's easy to copy and paste them into the config files. The --autounmask option is more like a better version of these "You need to change this USE flag for this package" messages, where you have to change stuff again and again.
In case a masked package pulls in for e.g... KDE 4.4.5 (assume it's masked), the user will not be notified much about the upgrade (or there wont be a big warning like there should be). This's what I'm afraid of, although I do have a habit of -pv before an emerge.
With --autounmask, if anything needs to be unmasked then emerge displays the necessary configuration changes and then exits immediately, without doing anything. So, the worst case from having it enabled by default would be for it to consume more time or for it to expose a bug somewhere in the --autounmask code.
(In reply to comment #6) > In case a masked package pulls in for e.g... KDE 4.4.5 (assume it's masked), > the user will not be notified much about the upgrade (or there wont be a big > warning like there should be). This's what I'm afraid of, although I do have a > habit of -pv before an emerge. > First thing to note is that it wont unmask stuff that is masked by package.mask. The only thing it does in this regard is to allow stuff with "~arch" keywords on "arch" systems. If one keyword change makes another keyword change necessary, then this second change will be displayed too. All changes have a comment added that tells the user the reason why this change was necessary.
It appears we have a bit of confusion around. I thought --autounmask has the ability to modify portage.unmask.
This is in 2.2_rc68, but I'll leave this bug open until it's in an unmasked version.
I think autounmask should add entries to package.keyword automatically. This was the thing I originally intended.
I would also like to see an option for fully-automatedness... (unmask, unkeyword, +use flags on dependencies needing recompilation, etc.)
(In reply to comment #11) > I think autounmask should add entries to package.keyword automatically. This > was the thing I originally intended. > You shouldn't blindly trust a tool to modify your config files. Just think of duplicated/overlapping entries, entries that contradict with existing entries, ... (In reply to comment #12) > I would also like to see an option for fully-automatedness... (unmask, > unkeyword, +use flags on dependencies needing recompilation, etc.) > What else than automatically modifying config files are you missing?
> (In reply to comment #13) > > I would also like to see an option for fully-automatedness... (unmask, > > unkeyword, +use flags on dependencies needing recompilation, etc.) > > What else than automatically modifying config files are you missing? Please see related bugs for background. I am interested in 'just do whatever necessary to get package X installed' functionality in a temporary, dedicated, virtualised environment. Having to write code to awkwardly work around each of the various potential reasons for a blocked package installation is stupid and not something a human should have to worry about in this situation. Whilst portage is great, it tends to be tailored towards human use, and the absence of automated issue-resolution functionality is a real limitation.
This is fixed in portage-2.1.9. Please file new bugs for any related feature requests or complaints.
Strange. I have 2.2_rc67 installed.
(In reply to comment #16) > Strange. I have 2.2_rc67 installed. If you're using portage-2.2_rc* then you need at least 2.2_rc68 for --autounmask support.
Ok.
*** Bug 215096 has been marked as a duplicate of this bug. ***
i think it would be a good idea to add the autounmask in its current state to the FEATURES. Then anyone can decide if this option should be on or off Also you could add a second option to also change the files if someone really wants that
You can set EMERGE_DEFAULT_OPTS="--autounmask" in /etc/make.conf if you want it enabled by default. It's not enabled by default now because it breaks app-portage/autounmask, it's not as well tested, and it doesn't support all same cases (package.mask is currently unsupported).
And also use.mask
Support for package.mask and missing keywords is in git now: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=0c71b9c673d6a96d62e0f1a037d70b3e9ea8339d http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=5eef84cb4b72695548937445019eac24f53d252b
Now there's also a --autounmask-write option to enable writing to config files (see bug 345775). All of the features of app-portage/autounmask should be implemented now, so --autounmask will be enabled by default: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=bd486e676cf4fb1893f8d06220c1f60ed04760f2
