Re: [Fink-devel] Automatic hiding of /usr/local
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 5/28/10 9:29 PM, Daniel Johnson wrote: On May 27, 2010, at 9:02 AM, Hanspeter Niederstrasser wrote: 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. Fink's db* packages fail to build if a /usr/local/include/db.h is present. I was seeing so many failure reports that I put code in CompileScript to check for it and terminate the build with a message explaining what was wrong and how to fix it. Since then I've not seen any such failure reports. Daniel Another option might be to have Fink check for /usr/local and issue a warning message that blocks further action without user intervention. Some users will complain about that, of course. - -- Alexander Hansen Fink User Liaison -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwE7PoACgkQB8UpO3rKjQ9XjwCdFW1y6lUTY31rcoxG/t4VcgG9 pkoAn2wrrrt3HXui0ZQ+4i08KxkDotay =2loq -END PGP SIGNATURE- -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Automatic hiding of /usr/local
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 6/1/10 7:20 AM, Alexander Hansen wrote: Another option might be to have Fink check for /usr/local and issue a warning message that blocks further action without user intervention. Some users will complain about that, of course. I should have added that this would only be done at the start of the build phase--not for every package. - -- Alexander Hansen Fink User Liaison -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkwE7TkACgkQB8UpO3rKjQ83pACeOccYEMU0lFUrYHKQ+2Z3ZRRk u1wAniKjBCmBIEMYWIkX7O6FRa4QiW3h =dBL0 -END PGP SIGNATURE- -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Automatic hiding of /usr/local
On May 27, 2010, at 9:02 AM, Hanspeter Niederstrasser wrote: 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. Fink's db* packages fail to build if a /usr/local/include/db.h is present. I was seeing so many failure reports that I put code in CompileScript to check for it and terminate the build with a message explaining what was wrong and how to fix it. Since then I've not seen any such failure reports. Daniel -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Automatic hiding of /usr/local
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
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
Re: [Fink-devel] Automatic hiding of /usr/local
Daniel, hidding /usr/local by temporarily moving it to another place sounds like a super-evil and dangerous thing to me. It's pretty easy to imagine how this can lead to data loss. Also, what if I want to build one of those super big packages that take hours and hours -- am I simply not allowed to use /usr/local during that time? It seems to me that such a feature should at most be used by power-users (or rather: by power-developers) who know exactly what they are doing. I wouldn't want to recommend this option to any regular user, nor to a regular developer. So I wonder why such a highly specialized thing should be in Fink -- can't those users just move the directory away themselves, or even better, not populate it in the first place? If we really want to enforce building w/o /usr/local visible for all our users, I think this is the wrong way to go. There must be better ones out there. What about setting up a chroot environment (which has it pitfalls, too, but at least the worst that can happen is a build failure and maybe some wasted disk space). Bye, Max -- ___ Fink-devel mailing list Fink-devel@lists.sourceforge.net http://news.gmane.org/gmane.os.apple.fink.devel Subscription management: https://lists.sourceforge.net/lists/listinfo/fink-devel
[Fink-devel] Automatic hiding of /usr/local
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.
We've previously considered and rejected the idea of *automatically*
moving /usr/local (or at least include/ and lib/) out of the way
during fink build operations because it's an out of /sw effect that
might affect other work the user is doing, and if the build fails, the
directories might not get put back in their original place.
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.
So...thoughts about a boolean fink.conf:HideUsrLocal flag, where TRUE
means rename/restore and FALSE/UNDEFINED means issue warning?
dan
--
Daniel Macks
dma...@netspace.org
http://www.netspace.org/~dmacks
--
___
Fink-devel mailing list
Fink-devel@lists.sourceforge.net
http://news.gmane.org/gmane.os.apple.fink.devel
Subscription management:
https://lists.sourceforge.net/lists/listinfo/fink-devel
