On Wed, Dec 12, 2012 at 06:53:57AM -0800, Jeremy Chadwick wrote: > (Please keep me CC'd as I'm not subscribed to the list) > > > > ===> Registering installation for MuSE-0.9.2_14 > > Installing MuSE-0.9.2_14... done > > pkg: sqlite: database is locked > > > > which results in muse not being registered in the pkg database... > > This worries me. It appears to indicate that the installation of the > package (i.e. sticking files into /usr/local) happens first, followed by > an attempted exclusive lock of the pkg sqlite DB, which then failed -- > thus leaving files laying around in /usr/local. > > If that is the case (and boy do I hope it isn't) then that logic is 100% > backwards. The DB exlock should happen first, and if the DB exlock > fails[1] then things should abort. Otherwise you'll end up with files > installed on your filesystem which aren't registered in the pkg DB, and > that is unacceptable. >
pkg install and pkg add doesn't do that at all. Just pkg2ng and installing from ports uses pkg register which does that, exactly the same way pkg_install does, pkg register knows how to do the clean way, just the ports tree doesn't know yet how to do it, I have patched for that unfortunatly it breaks compatibility with pkg_install (the solution is to use a stage directory inside the ports tree) If you are worried by this, do not ever have a look at how the pkg_install works :) > This also worries me: > > > ... This persists between reboots, and for fresh pkg runs. > > What kind of locking mechanism is being used here? flock(2) LOCK_EX > would not survive a reboot, but a filesystem-based dotlock would. It is the sqlite native lock system which is a flock so it should not survive the reboot > > This really needs investigation and not be swept under the rug. And > please don't tell me "you have the source, go look at it" -- I would > much rather the authors who are familiar with the code look at it. :-) > > [1]: I don't advocate that the locking mechanism should block > indefinitely, but there should be some kind of retry attempt at a > specific interval (i.e. try 5 times, with 1 second delays) before giving > up -- and something on-screen should be printed/shown every time an > attempt to lock is made. Maybe that already happens, I don't know, I > don't use pkg. This is already in, and we have a lot of work for a finer grain locking system. Anyway the reported issue is really strange and need way more details to be able to be investigated. regards, Bapt
pgpKsiQI2IxDX.pgp
Description: PGP signature