>>> On Friday, 26. October 2007 at 11:40 pm, J P wrote: > once the installation is setup everything appears to be hard-coded to > that directory structure. [...] playing with the openpkg installation > script "openpkg-20071019-20071019.sparc64-solaris9-openpkg.sh" it > appears that the USERNAME, GROUP, and PREFIX PATH that was used to > compile the script is hardcoded in 100's of places in the file [...] > This observation is correct. I want to emphasize that this behavior is not limited to the bootstrap but is also true for a lot (albeit, at least in theory, not all) of the packages. This works as designed.
Too many applications suck information from their build environment into their binaries. OpenPKG assumes that it is not possible to create packages which are truly independent from their prefix, user and group names and ids. You may feel there are a lot of packages where the goals "relocation" and "user/group name/id independence" could be achieved but there are too many where these goals are unreachable. It is often even hard to create packages which are build in an area different from their final installation path, but this goal is mandatory for OpenPKG and some packages must be already tweaked a lot to achieve even this goal. > My question is that once we create a "unique" installation script for > each set of servers will we be able to safely reuse the same binary > RPM files that were originally created under the > /export/home/tambu/openpkg directory? Or do we have to recompile > everything including all the perl modules? > You can build binaries from sources for arbitrary prefix, user and group names and ids. You specify these parameters when building the bootstrap from source. As you already found out, they will be hardcoded into the bootstrap binary. All packages you build from source using this bootstrap will inherit these parameters and also have them hardcoded. The simple rule is: build binaries from source for every prefix, user and group names and ids combination. Then deploy these binaries to one or more machines which use exactly the same combination. If you want to see the available options which can be passed to the bootstrap build process or even want to pull the actual values from an existing bootstrap, please review my "cloning OpenPKG: bootstrap" [1] article. [1] http://www.lotterer.net/blog/en/41 -- http://thomas.lotterer.net ______________________________________________________________________ OpenPKG http://openpkg.org User Communication List openpkg-users@openpkg.org
