Ok, so I have a problem that seems to be able to be replicated where the update doesn't work for binary rpms on client systems. Perhaps this will help you help me out with this issue. Here it is...
1. Rebuild and install all release src rpms with only the default options on a separate build server. For the sake of consistency and the feel of a clean room type setup, do this test as root where the environment is identical on both servers. 2. Copy all of the created binary rpms into some sort of repository for client systems after which build a new index file for them. 3. On a client system of like hardware architecture and OS, install only the binary rpms created on the build server using a command like: `openpkg build -r /the/repos/path/ -p $arch -f /the/repos/path/index.rdf -A -i | sh` 4. Create a build file under root's home dir at ~/.openpkg/build which should exist on all systems with the following options: -Dtcl::with_x11=yes -Dpostgresql::with_server=yes -Dpostgresql::with_odbc=yes -Dpostgresql::with_tcl=yes -Dpostgresql::with_perl=yes The focus rpms in this example are tcl and postgresql. The tcl package requires with_x11 when you enable with_tcl for postgresql. 5. Now go back to the build server and rebuild the tcl and postgresql packages. Some problem here caused me to have to manually rebuild tcl and force install the resulting binary rpm. I received this error message when initially trying: "FATAL: errors occured while building: postgresql-7.4.3-2.1.0: postgresql has conflicting requirement" Afterward, the openpkg tools found that postgresql needed to be rebuilt with new options and did so. 6. Copy the newly rebuilt binary rpms into the repository you created previously and regenerate a new index file. 7. Go to the client system and attempt to update the system using a similar command to the one in step 3. I initially received the same error I showed in step 5 but after I force installed tcl, then it caught that postgresql had an option update and installed properly. This seems to be a consistent problem and should be able to be reproduced. The problem here is that the client update fails even though the build file does exist on all systems. I have had a similar problem with OpenSSH and GCC, though not with some other packages. It seems to only affect some rpms and not all. Can anybody help me resolve this issue because currently it is a major stopping block as the client systems aren't getting their updates automagically as they should due to this error? Thank you. -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu
signature.asc
Description: This is a digitally signed message part
