Simple modifications to: usr/bin/dep-clean usr/lib/portage/bin/portageq usr/lib/portage/pym/portage.py etc/make.globals Reproducible: Always Steps to Reproduce: 1. Read the patch 2. Apply the patch 3. Play with the patch Actual Results: PACKAGE_UNMASK is now configurable in portage vs statically coded dep-clean ignores any packages found in $PACKAGE_UNMASK After dep-clean is in python, it can re-use some portage code to parse depenancy information [ DEPEND=">=dev-lang/tcl-8.4 virtual/jdk" ]
Created attachment 23717 [details, diff] Patches 4 files for use with /etc/portage/packages.unmask Read the patch. You'll see what I did.
This is IMO too special to consider. If it would make the /etc/portage location configurable I'd consider it, but just some files is a bad idea. Rework it if you want, otherwise I'll close this as wontfix.
Created attachment 24117 [details, diff] updated patch Updated patch, dep-clean now uses ${PACKAGE_UNMASK}
maybe i'm missing something but all this does is remove entries that are in /etc/portage/package.unmask from the world file ?
This patch does several things. In short, it adds support for PACKAGE_UNMASK and makes PACKAGE_MASK configurable in emerge. It also crudely adds support for package.unmask in dep-clean. Whomever hardcoded /etc/portage/package.mask in portage.py had a nice idea, but didn't finish the job (and should know better than to hardcode something like that). *** The files and changes are as follows: /usr/bin/dep-clean -- Remove contents of package.unmask from the world file before processing /usr/lib/portage/bin/portageq -- Add definition for package_unmask /usr/lib/portage/pym/portage.py -- Add support for PACKAGE_UNMASK option, needs to be revisited for PACKAGE_MASK, which was hard-coded before /etc/make.globals -- Add defaults
ok, thats cool ... but wtf is -A|--automatic for ?
-A|--automatic allows one to optionally use the 'new code' in dep-clean. "It works for me." isn't exactly good QA policy. Feel free to to remove the -A option and the elif, etc, etc. It's the functionality I wanted to get into the tree. Is the fact that I put what probably should have been 2 patches into 1 confusing you? One patch is for dep-clean, the other is for emerge... both came about because of a hard-coded '/etc/portage/package.mask' in /usr/lib/portage/pym/portage.py
As I said before IMO it's not a good idea to make package.{un,}mask special cases. And adding a new env var for each portage config file is not an option from my POV.
