On Fri, Aug 06, 2004, Ralf S. Engelschall wrote: > On Thu, Aug 05, 2004, Alexander Belck wrote: > > > I don't know exactly what is needed for the openpkg_binaryies. > > I set up the sugested opa() function and after login I issue opa /opkg. > > That works nice, but if I need to execute a bin without login ? > > Is it fine to give the full path for the openpkg binary without prior preparing > > the environment (without opa /opkg) ? > > Sure, just run the "foo" program via "/opkg/bin/foo". > Call me a pessimist but it's not always that simple. Of course it is correct that any application can be launched using the full path. But what's further going on entirely depends on the application. Some apps are simple filters that don't care about the rest of the environment and everything works fine as expected. Others have to load configuration files or run child apps. You have to know how the app finds it's config. If it is using, say $HOME/.prefs, then no matter how you launch the app it will find the prefs. This can be an advantage if you have multiple versions of the app that are prefs compatible and you want to test a new version. The same concept becomes complicated if the different versions call for different prefs formats. Also if an application needs to run another app the success of the entire procedure depends on how the second app is found. Imagine variants like "same dir", "current working directory", PATH, config, hardcode ... At least OpenPKG tries hard to ensure that any application reading a fixed config file, i.e. $PREFIX/etc/foo/foo.conf, will get that path hardcoded into the binary at built time so two instances are really separate and use their config. You can be sure that the "openpkg" command is fully aware of it's related environment but this is only one of many programs. In the end, this is a question not directly related to OpenPKG - only the multi instance feature of OpenPKG makes the question coming up more likely than traditional environments.
> > Also, is there any proplem using one server from the underlaying OS that > > integrat with services run from OpenPKG at the same hoste ? > > [...] > It is as easy as integrating services run on different hosts: they need to listen on different IP/Port combinations. The "same host" approach allows sharing the IP and only sepating the port. In addition, the "same host" approach allows intermixing by calling applications across OpenPKG instances, i.e. a Webserver CGI in one instance can call "sendmail" from another instance or even from the OS. Beware that such mixtures lead to interrelationships which will cause headaches when it's upgrade day. -- [EMAIL PROTECTED], Cable & Wireless ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List [EMAIL PROTECTED]
