On Fri, Sep 02, 2005 at 09:32:02AM +0900, Garrett Cooper wrote: > On Sep 1, 2005, at 9:52 PM, Alexander K. Hansen wrote: > > > >The "stale buildlock" problem isn't within the scope of 0.24.10 to > >resolve (especially because they are not infrequently generated by > >impatient users hitting ^C too vigorously. :-) ). There are plans > >for a cleanup routine to remove buildlock packages--this has to be > >done carefully so that it doesn't destroy the lock for something > >that's still being built. > > I know it might be a silly assumption, but why not check for any > running fink PIDs if there is a preexisting software lock, then if > there aren't any, remove the stale lock and start the build/install > process over again.
Buildlocks are designed to *allow* parallel fink processes to run safely, and it's not hard to have multiple non-stale locks present concurrently. One must check that the lock really is stale, i.e.. the fink that created it is dead, not just "no finks running". The lock structure contains the pid of the fink process that created it (similar to how many server daemons store a /var/run/foo.pid file). Now we're just waiting for someone to write a function to gather all lock structs, check each for staleness, ask user if each stale lock should be nuked". As usual, anyone with some perl ability is welcome to contribute to the effort:) dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Fink-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-users
