pena cacao # /usr/lib/portage/bin/clean_locks You must specify directories with hardlink-locks to clean. You may optionally specify --force, which will remove all of the locks, even if we can't establish if they are in use. Please attempt cleaning without force first. /usr/lib/portage/bin/clean_locks /usr/portage/distfiles/.locks /usr/lib/portage/bin/clean_locks --force /usr/portage/distfiles/.locks Just make /usr/portage/distfiles/ in the example be the actual DISTDIR and users can just copy - paste the line.
Automated lookup would be pretty damn slow, portageq call. The *really* fun thing is that hardlink locking can be used in other places then distdir- if there is a crap lock sitting around, it could deadlock portageq. Don't like that possibility...
(In reply to comment #1) > Automated lookup would be pretty damn slow, portageq call. > Why portageq when clean_locks is implemented in python?
Bleh, pardon, still doesn't matter if it's portageq or direct access to portage. Portage does a couple of nasty things during import, what I'm questioning is the possibility of triggering a deadlock via the portage import; random crazy example is cleansing of incomplete merge in vdb while doing the forced virtuals lookup (vdb cpv_all walk).
(In reply to comment #3) > > Portage does a couple of nasty things during import, what I'm questioning is > the possibility of triggering a deadlock via the portage import; random crazy > example is cleansing of incomplete merge in vdb while doing the forced virtuals > lookup (vdb cpv_all walk). > Well then this will probably have to wait until portage is more modular and one can just import the needed parts.
people have already resigned themselves that portage-related stuff is going to be slow, so i dont see why we cant throw a portageq into this mix
zmedico modified portage to do delayed loading of virtuals- should be possible now without 10s delays for instantiating crap we don't need... Eg, someone split a patch. :)
This is fixed in svn r3188.
Released in 2.1_pre10.
