Re: [Fink-devel] Automatic hiding of /usr/local

[Hanspeter N. <fi...@sn...>]

On 05/27/2010 12:37 AM, Daniel Macks wrote:
 > One of the side effects of fink-package-precedence is that /usr/local
 > becomes more of a visible problem. Well, it was always a problem, but
 > now it becomes a build-time crash rather than a silently-lurking
 > time-bomb). There are lots of legitimate reasons users may have
 > /usr/local stuff, but no good technical way to hide it from the
 > compiler.
...
 > Murr suggested a fink *option* to do it. I agree it's a nice feature.
 > Some ideas he and I kicked around include having fink warn if
 > /usr/local stuff is detected, and having a fink.conf opt-in control
 > that does the rename-while-build-then-restore. And vasi's "Finally"
 > feature (used by the BuildConflicts swappy and Buildlock removal
 > processes) to restore seems to provide a way to restore the moved dirs
 > even in most cases when the build fails. My only concern is for
 > parallel build operations ('fink build a' and 'fink build b' in
 > separate windows)...need to make sure the restore only happens when
 > *all* builds are finished, which may also not be the same build that
 > did the move originally.

What about when the fink process itself crashes during a build when 
/usr/local has been 'hidden'?

During my last buildworld, I had lots of problems with the computer 
(apparently passwd doesn't like being nice'd, backgrounded, and its 
terminal closed), and upon reboots where the fink process itself was not 
terminated cleanly, either leftover buildlocks or dpkg/status editing 
had to be manually taken care of (no surprise that this happened, since 
there was no clean termination).  Will the user in dirty terminations 
have to manually unhide /usr/local?  And what if the crash happens in 
the middle of the hiding/unhiding and things are only partially restored?

 > So...thoughts about a boolean fink.conf:HideUsrLocal flag, where TRUE
 > means rename/restore and FALSE/UNDEFINED means issue warning?

Besides gccXX (and local/libgmp seems to be the most common culprit 
there), are there other packages that routinely suffer from /usr/local 
interference?  A CompileScript check for /usr/local in those packages 
could similarly be done.  If the same underlying mechanism as buildlock 
removal and BuildConflicts is used, based on my experience with it, I'm 
not sure it's robust enough, and in this case it will be affecting 
things _outside_ of %p.

Hanspeter