Date: Tue, 28 May 2002 23:02:17 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Greg 'groggy' Lehey <grog@FreeBSD.org> Cc: "M. Warner Losh" <imp@village.org>, peter@wemm.org, freebsd-arch@FreeBSD.ORG Subject: Re: Why don't we search /usr/local/lib and /usr/local/include by default? Message-ID: <3CF46EE9.6C6030C0@mindspring.com> References: <20020529093009.C31668@wantadilla.lemis.com> <20020529012544.14816380A@overcee.wemm.org> <20020529122327.C82424@wantadilla.lemis.com> <20020528.221453.83474290.imp@village.org> <20020529140813.P82424@wantadilla.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg 'groggy' Lehey wrote: > > We shouldn't search /usr/local by default because PREFIX can be set > > to anything. > > It doesn't do any harm even in that case. Actually, in this case, it can. > > We shouldn't search it because that may break other things. > > What? The issue with "PREFIX" is that it's used for the "ports" system, including "packages". There _is_ actually a way that this could be bad. The place it would be bad is for ports maintainers and ports users (but not packages, since they will get caught during the build process). The way this could go sour is to hide dependencies. Consider a port maintainer who has a working system where they do ports. This system may have things installed on it that the port maintainer uses in everyday use of the system -- when the box is not being used to maintain the port. In this case, what this means is that an updated version of software could grow a dependency on the installed software -- _because the compiler finds it without being told_, ad the port maintainer may not become aware of this situation at the time of the port _because the compiler finds it_. IMO, this is *probably* what happened with the recent "getopt_long" problem that someone posted about to both -ports and -hackers. FWIW, "PREFIX", in my book, is not a "ports-only thing". That makes an argument against the extension your Linux friends want, based soley on "PREFIX", pretty specious. I'd also argue that ports should be maintained in a jail, so that this is never an issue; we know already that we can have mistakes in found dependencies, even if the linker and the autoconfig process is too stupid gto catch them: that's why the packages build farm is a farm, and why it requires "clean" system images to build out the packages prior to a FreeBSD release. Without a "portsjail" port, though, this is unlikely to magically happen all on its own. FWIW, I think that the developement environment should cater to the developer. You can argue this both ways: that it should be a minimal set, or that it should "just work". I don't think it's correct to try to make the "PREFIX" argument on the basis of ports maintainers, though, since they aren't really the majority of developers. On the other hand, it's pretty self-evident that the rules for doing compiling (include paths) are different from those for linking (library paths) are different from those from running (ldconfig cache contents), and that these three things should at least *try* to be the same. My own perspective, having used FreeBSD as a developement platorm for code to be deployed on AIX and Solaris... is that FreeBSD "comes with" too much crap. The OpenSSL stuff along means that any code I develope without paying particular attention, is automatically unportable, since I may forget to import the OpenSSL sources into my source tree, incorrectly assuming that the OS will provide the support for me (this is not true!). In general, I have to say that the FreeBSD ports system itself doesn't take these dependencies into account very well (I guess it would be the "Open Ports" system, if it did, since that would mean it would run on any minimal POSIX compliant system, not just FreeBSD). It's very hard, IMO, to argue against including well known add-on include and library paths in the compiler and linker, when they are there in the ldconfig library path cache, and OpenSSL is in the base system for FreeBSD, but not other OS's: the PREFIX argument is a portability argument, and you can't make one portability argument without making *all* portability arguments. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3CF46EE9.6C6030C0>