On Thu, Sep 18, 2008 at 11:02:51PM +0200, Martin Costabel wrote: > William G. Scott wrote: > [] > > On Sep 18, 2008, at 7:48 AM, Alexander Hansen wrote: > > > >> I did, though. In consultation with Dan Macks we found the following: > >> > >> $ type -a xml2-config > >> xml2-config is /sw/share/xtal/ccp4-6.0.99e/bin/xml2-config > >> xml2-config is /sw/bin/xml2-config > >> xml2-config is /usr/bin/xml2-config > >> > >> That shadows the "normal" xml2-config. A quick hack would be to > >> rename or remove ccp4's xml2-config. > > This exposes an IMHO dangerous feature of fink's build process: In order > to set up its default build environment, it runs /sw/bin/init.sh and > therefore executes all the scripts in /sw/etc/profile.d/ (in PkgVersion.pm). > > I think it would be much more robust if fink constructed its PATH > explicitly (and perhaps some other env vars, if it they are needed) and > didn't leave this to the the init scripts that depend on random > installed packages.
Many of the env vars set by profile.d scripts are critical to the functioning of their packages. Disabling that breaks the package, which means it can't be used as a BDep if it's disabled during the package-compiling routines. The only issue here is that some packages have a ton of executables and so stash them in a private bin/ (or else that's how the package's upstream requires it to be built), and then adjusting PATH makes it harder to see exactly what executables are visible. For example, if ccp4 dumped everything in /sw/bin, we'd've seen the filename collision with libxml2's xml2-config script a long time ago (or at least users would not have gotten as far as compiling something that BDep:libxml2 while also having ccp4 installed). > It would then even be possible - as has often been suggested - to place > /sw/bin:/sw/sbin at the *end* of PATH in the standard user environment > while keeping it at the beginning of PATH in fink's build environment. The only limitation here is that any package that calls any executable that could also exist somewhere other than fink needs to hard-code the path to make sure to get fink's. That is, the opposite case as gitk a few days ago. There's a *lot* to be said for hardcoding the path *always*, because you never know what a user's gonna do, or what third-party (or new X11 release) is going to suddenly add or change. Another advantage of hard-coding is that it reduces the problems for users who don't load the init.sh at all, and therefore don't have /sw/bin in PATH anywhere. These users are still likely to have lots of weird issues because of other env vars and whatever-else that the scripts would have done that the packages expect and require. But at least it's *some* help. Fink itself and some other critical packages do hard-code because they need to run in "unimproved" shells. OTOH, I wonder how many packages that set env vars in profile.d could instead just use a wrapper script around the actual executable? I'm sure some, I know not all. > Or is there some logical reason why the fink build environment should be > the same as the user shell environment? I don't see any such reason. Concurred. No need for this on its face, as long as a fink package works "the way it should" in either situation. dan -- Daniel Macks [EMAIL PROTECTED] http://www.netspace.org/~dmacks ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Fink-devel mailing list [email protected] http://news.gmane.org/gmane.os.apple.fink.devel
