Yes, this is indeed not very good behaviour. It should be remedied along the sticky flag dependency development. Please submit the proper bug report (I did not find one in a quick search for "autoclean") so that this issue won't get forgotten. Meanwhile you should probably choose to stay clear from combining all three of: 1. KEYWORDS="~arch" emerge pkgname (adding "~arch" to make.conf should be safe in *that* respect, though clearly you may not want to do this for other reasons) 2. AUTOCLEAN="yes" and 3. emerge -u world (basically, this is a classical "choose any two" situation). George On Sunday 15 December 2002 06:09, Cong wrote: > Recently portage behaves really strangely on my system. > When I do "emerge clean", Portage trys to clean newest packages > For example with phoenix-bin: > > # emerge net-www/phoenix-bin > SUCCESS > # emerge net-www/phoenix-bin -p > [ebuild R ] net-www/phoenix-bin-0.4-r2 > # emerge net-www/phoenix-bin -cp > > >>> These are the packages that I would unmerge: > > net-www/phoenix-bin > selected: 0.4-r2 > protected: 20021121 > omitted: none > > And the problem is that this happened with sys-apps/portage itself, > i.e, after upgrade previous version to portage-2.0.45-r5, portage > cleaned sys-apps/portage-2.0.45-r5 ( it tried to kept > sys-apps/portage-2.0.45-r4) and portage got broken. Same things > happened with almost all packages: gcc, glibc, xfree .... > > Now I am forced to put AUTOCLEAN="no" in /etc/make.conf . > > / Cong
Created attachment 6553 [details] /etc/make.conf My /etc/make.conf
You have bad/corrupt counters. Either.... Wait until .46 comes out, delete your global counter, and then emerge something. Hopefully your counter can be restored safely, or you'll have to do some hand editing of the files. Or do this: (Which is what portage will do in .46) for FILE in $(find /var/db/pkg -type f -name COUNTER); do cat ${FILE}; echo done | sort -n | tail -n1 | tr -d '\n'" > /var/cache/edb/counter If after this your counter isn't a reasonable number (less than 11 digits) you'll have to do some serious work to fix it up.
The global counter on my box was correct. I compared the output of the script you provided with it and they are the same. I spent a time to manually clean all of old packages, and currently enable AUTOCLEAN="yes" again in /etc/make.conf to see what will happen. I wonder if the problem was the system time. Do you know what will happen if , for example, #emerge =dev-util/anjuta-1.0.0 at 2004/01/01 (when system time is incorrect) #emerge =dev-util/anjuta-1.0.1 at 2003/01/01 #emerge dev-util/anjuta --clean at 2003/01/02
mtimes are only right or wrong. No consideration for older newer. Can't get anymore info to figure this one out.
