No subject

rarob at rarob at
Tue Jun 9 18:54:11 UTC 2009

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
  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.



More information about the Rpm-list mailing list