We probably need to a graceful way of handling an entire package being masked and in /var/cache/edb/world when doing an emerge --update world. # emerge --pretend --update world These are the packages that I would merge, in order. Calculating world dependencies \ !!! Error: couldn't find match for net-im/licq in update (likely old /var/db/pkg entry)
*** Bug 1856 has been marked as a duplicate of this bug. ***
Are you sure that this is indeed a duplicate of bug 1856? I looked at this one before posting 1856, but it sounds like something different, since this one seems to be about a whole package being masked out, and the bug that I encountered is basically about not checking for existence of a directory before trying to open a file in it.
I'm pretty sure this bug is fixed in 1.9.1 or earlier. I can't replicate the problem here with 1.9.1.
Created attachment 731 [details] portage exception definitions and generic handler
Created attachment 732 [details, diff] patch to solve this problem ;)
Hi Daniel, hi guys. I completed updated patch to address this problem: \begin_quote If the package was moved/renamed or masked completely (like openoffice* for example) after it has been installed and included into world file, emerge --update world reports error and exits. \end_quote (and I need this corrected before I will start moving apps into app-sci, otherwise emerge --update world will be broken for users who installed relevant packages. And apparently it is not fixed up to portage-1.9.5, as this was why I started on it). So now (with new patch) emerge behaves correctly: First it scans /var/cache/edb/world. If some package listed in it is problemmatic (match cannot find it), then it reports the problem, comments out relevant entry in world and continues. Then with updated world file it proceeds as usual - so that it reports and halts on incorrect dependencies. Patch should apply cleanly to portage-1.9.5 (portage_exceptions.py should probably reside in site-packages next to portage.py and output.py or any other place as long as python finds it). I reopen the bug until changes are incorporated or some other solution is found. BTW along the way I introduced proper error handling mechanism - through exceptions (it is necessary in this case as match should handle errors differently based on where it was called from). There are two classes defined and generic exception handler hooked (so that user gets error message instead of traceback for portage exceptions. All standard exceptions will be passed and result in a traceback as at present). All this is done in portage_exceptions.py. This has to be separate file as this functionality may be desirable elsewhere in the portage. In fact it is really easy to convert error handling to exceptions: just import portage_exceptions (this hooks handler automatically) and then replace: print "doing harakiri now" \n sys.exit(1) with: raise GenericPortageError(message) This will default to reporting the problem and exiting (as done now), but it will also be possible to easily override this behavior at the specific spot. (Sorry for these basics, but I feel it is important to handle errors in a proper way). George
Few Cosmetic updates to the patch. Should apply cleanly against emerge - 1.90 (cvs).
Created attachment 754 [details, diff] updated patch
Created attachment 755 [details] just a cosmetic touch (\n at the beginning of error message, so that it looks better)
Created attachment 866 [details, diff] updated patch to emerge to handle the problem Updated the patch to make it apply cleanly against 1.9.9 (emerge-1.93).
