Hello all, Got a question on how best to (re)package our software for distribution. I'm still doing some more research into the back-issues of the rpm list as well, but haven't seen anything back through Sept '07. Our software consists of a base rpm and 3 or 4 optional rpms that all depend on the base package. The version number for all of our installed rpms must match. Up until now we've had a flat directory with all of our rpms for our supported platforms and used a custom script to id the OS and selected the appropriate rpms to install. This script is run for all install/updates. We're trying to change this instead to have a local yum repository structure, which will (we hope) allow for a cleaner installation and update process, especially in a environment where our customers may have a networked yum repository. This works fine, except for a wrinkle where we've changed how our code is built. For discussion, let say the old way had the following packages: foo-1.1.1 (required) foo-gui-1.1.1 (optional, requires foo-1.1.1) foo-docs-1.1.1 (optional, requires foo-1.1.1) foo-extras-1.1.1 (optionsl, requires foo-1.1.1) We've changed how things are built now, and what use to be foo-docs is not part of foo-gui, so we have this: foo-1.2.1 (required) foo-gui-1.2.1 (optional, requires foo-1.2.1) foo-extras-1.2.1 (optional, requires foo-1.2.1) Any suggestions on how to craft our spec files (or yum repo info) so that if we are installing the foo-1.2.1 rpms the foo-docs-1.1.1 package is correctly identified as obsolete and removed? Ideally we would like to be able to eventually do a 'yum groupinstall foo-group' to either install or update our software and have it do the right thing. We really don't want to require the user to remove the software first before installing the newer code, as there are some user modified files that we need to keep track of and re-import. Thanks.... Rob _______________________________________________ Rpm-list mailing list Rpm-list@xxxxxxxxxxxxx http://lists.rpm.org/mailman/listinfo/rpm-list
