On 12/23/13 6:52 PM, Alexander Hansen wrote: > On 12/23/13 6:16 PM, Mark D. McKean wrote: >> I was doing a sweep of my hard drive today, looking for stuff that might >> be unexpectedly eating up space. And OmniDiskSweeper said there was 2 >> gigs in /sw/src/fink.build. When I looked at it, I saw several folders >> there the names of which corresponded to packages I had attempted to >> build but which had failed. All of the packages in question had since >> been fixed and successfully built, or I had at least temporarily given >> up on them, but the incomplete build files remained there. >> >> I checked the man page for fink, but couldn't find any commands or >> options that claimed to delete failed or uncompleted builds. I ran "fink >> cleanup --all", but those failed builds were not among the items removed. >> >> So my question is twofold: >> >> 1) Is there any risk in my simply rm'ing those failed builds directly? >> As I mentioned, the packages in question have since been built >> successfully (or abandoned), so there shouldn't be any reason to keep >> the failed builds around, but I don't know if there's some internal >> index fink keeps that might get messed up if I manually delete them. >> > > It's completely safe to rm or Trash them. They only get kept around > because they potentially contain useful debugging information, and > nothing else should be using them--if that happens it's a packaging error. > >> 2) Is there an option or command somewhere that I'm missing, something >> that would remove failed builds either automatically upon failure or >> manually on command? Or is manually rm'ing failed builds out of >> /sw/src/fink.build periodically the only way to keep them from hanging >> around indefinitely? If there is no built-in option, is that something >> that could be looked at as a possible additional mode for cleanup? Or is >> there some reason I'm not aware of to keep failed builds around? >> >> Mark D. McKean >> qpa...@quantumpanda.com >> > > There's not a currently such a fink mode, so manual removal is currently > the only option. > > "Automatically on failure" is undesirable, for the reason I mentioned > earlier--there is quite a bit of information that can be grabbed from > the build directory in the even of a failure, so it's best to leave it > around. > > I can't think of a good reason why it shouldn't be a "cleanup" option, > though. A situation where revision A fails on some platform and then > the fix entails revsion A+1, say, which leaves the revision A build > directory behind is pretty common.
I just thought of a potential pitfall that would need to be addressed. We'd need to ensure that the contents of a build directory which is in use by an active build couldn't be erased via issuing a "cleanup" command in another shell session--the buildlock system would probably be of use here. -- Alexander Hansen, Ph.D. Fink User Liaison My package updates: http://finkakh.wordpress.com/ ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ Fink-beginners mailing list Fink-beginners@lists.sourceforge.net List archive: http://news.gmane.org/gmane.os.apple.fink.beginners Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-beginners
