As the user apparently isn't able to report... http://forums.gentoo.org/viewtopic.php?p=3816495 I think the posted output speaks for itself - no!?
The counter is quite important since the emerge --clean phase uses it to ensure that the most recently installed package within a slot is kept. We'll have to add some counter regeneration code to emerge and warn the user if there are more than one package in a given SLOT but no COUNTER to distinguish which was most recently installed.
In svn r5465 I've applied a minimal fix that simply assumes the counter is zero (that's what the original code intended to do but failed).
*** Bug 160679 has been marked as a duplicate of this bug. ***
If you say setting it to zero is fine, then I do not oppose it. But what I was thinking about is Portage acting a bit more gracefully, than a plain backtrace; Telling users their db is broken, that they may want to run fsck in case of underlaying problems and how to fix it. In the case I helped the user to fix in forums.g.o it COUNTER and SLOT files were missing. How does Portage deal with other files missing - tracing it back, without providing any user friendly information, I suppose !? Even if Portage is fixing it silently, it should throw a message telling the user about it and that he might check his fs or what else he or his tools might have done.
Created attachment 105917 [details, diff] Fix the ValueError reported in bug #160679 If this patch is saved as /tmp/counter_regression.patch, then it can be applied as follows: cd /usr/lib/portage patch -p1 < /tmp/counter_regression.patch (In reply to comment #4) > If you say setting it to zero is fine, then I do not oppose it. But what I was > thinking about is Portage acting a bit more gracefully, than a plain backtrace; The backtrace reported in the forums and in bug #160679 is a regression that's fixed by the attached patch (svn r5465). > Telling users their db is broken, that they may want to run fsck in case of > underlaying problems and how to fix it. > > In the case I helped the user to fix in forums.g.o it COUNTER and SLOT files > were missing. How does Portage deal with other files missing - tracing it back, > without providing any user friendly information, I suppose !? It depends on the use case. The error handling could probably use some improvement. > Even if Portage is fixing it silently, it should throw a message telling the > user about it and that he might check his fs or what else he or his tools might > have done. In some cases it will print a message to inform the user of corruption and it will advise them to run /usr/lib/portage/bin/fix-db.py. I've never used that script so I'm not sure how helpful it is. Anyway, I'll see about improving the error handling and see if the script needs any work.
(In reply to comment #5) > I've never used that script so I'm not sure how helpful it is. I haven't either, as I had no broken db (well, at least no missing files) yet. :) It was the quickest way to let the user find out, which files were not o.k., as portage did not report which files were broken. Finding that out is the one part and not the problem for Portage. The problem is (for a share of our user base at least) to think about doing rm -rf /var/db/pkg/$cat/$ebuild and emerge --oneshot afterwards. Another question is, when to advise this. When there are lots of errors or the fs is even screwed simply reinstalling packages hides the real problem at best. > In some cases it will print a message to inform the user of corruption and it will advise them to run /usr/lib/portage/bin/fix-db.py. Yes, I stumbled about it by looking at the code. Nevertheless, a broken dummy db as test case (missing, empty, fuzzed files) Portage had to pass before a release wouldn't harm.
