On Fri, Mar 27, 2009 at 09:56:53AM -0400, Alexander Hansen wrote: > This is the expected behavior. Something in how our lynx package builds > relies on behavior from a system utility that differs between the > built-in version and that from coreutils-default. (I haven't looked at > it, but it might be possible to do something different here, such as to > include full paths so that things like "mv", "cp", and "install" are > guaranteed to be the system's version). After lynx is built there is no > such conflict. > > As the message says, coreutils-default will be removed while lynx is > built, and then reinstalled afterwards. If there's a build failure, > coreutils-default will still be reinstalled. > > Basically you just won't have coreutils-default while you're building > lynx.
While building itself, lynx autodetects a bunch of command-line utilities and hard-codes their paths into lynx itself. If we *allow* it to see coreutils-default, we have to *force* it to see it on all systems (so that the build always winds up the same way) and set a runtime Depends on it so that the package will actually be able to use those paths it found. Or we could just make sure it *doesn't* see any coreutils-default commands when it builds, and then we don't force all users to install that package and keep it installed just to use lynx. Given that the cu-d commands do behave a bit differently, I really hate the idea of forcing them into the users' PATH. It's probably possible to override the lynx path detection (hardcode the apple path even if cu-d is present)...someone who is bothered by the current hackish solution is welcome to try to improve it obviously. dan -- Daniel Macks [email protected] http://www.netspace.org/~dmacks ------------------------------------------------------------------------------ _______________________________________________ Fink-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/fink-users
