Currently, when a package is emerged and then unmerged, it produce 3 logs files if PORT_LOGDIR is set: - one at build time (doebuild uses current global counter + 1) - one for preinst/postinst (global counter is increased, and then doebuild use current global counter + 1) - one for prerm/postrm on unmerge (current + 1 again) I think a single log file is enough for a package life cycle. So I've made the following changes: - at build time, use "current + 1". This is still the default for doebuild. - at merge time, use the new current value. doebuild receive it from treewalk as an optionnal parameter. - at unmerge time, use the value from the db entry COUNTER file. It works fine with emerge, but it's not perfect: you can break this scheme using ebuild. For instance: - ebuild foo/bar compile - emerge something/else - ebuild foo/bar install qmerge will results in two log files for foo/bar. But I think that's still better than the current situation. Reproducible: Always Steps to Reproduce:
Created attachment 23324 [details, diff] log_counter.patch This patch is against 2.0.50_pre10.
Created attachment 23789 [details, diff] log_counter.patch Updated for 2.0.50_pre15.
Created attachment 24248 [details, diff] log_counter.patch Updated for 2.0.50_pre19.
TGL, you up for updating this?
Created attachment 52359 [details, diff] 2.0.51.18-portage.py-log_counter.patch Here it is, with basically no change but a rediff. (Sure, i've checked that it still makes sense and works, and it does. Actually, it seems that there had been no change to the counter logic since 2.0.50.)
I want to say closed due to logging in CVS, jstubbs, this have potential for entry into stable...or drop and say CVS logging from genone is good enough?
What logging are you talking about? I've not followed CVS closely lately, but if it's the e{info,warn,etc.} messages logging, it doesn't have much to do with this patch. PORt_LOGDIR is a different beast. Could you precise what you mean? Thanks.
/me didn't look at the patch closely enough apparently. I see the behavior you describe in my own LOGDIR.
Personally, I prefer HEAD for this. It's more about abnormal behaviour than incorrect behaviour and there might be existing tools relying on the abnormality.
something for trunk?
This is solved in 2.1.1. Portage now uses the timestamp of ${PORTAGE_BUILDDIR}/.logid instead of the counter. It was fixed in svn r3506 for bug 136285.
