[RFC] additional enhancements for RHEL3/4 for Dell system-specific repo
Michael E Brown
Michael_E_Brown at dell.com
Thu Apr 5 16:35:26 CDT 2007
On Thu, Apr 05, 2007 at 04:33:06PM -0400, Ben Scott wrote:
> On 4/5/07, Matt Domsch <Matt_Domsch at dell.com> wrote:
> > If/when OMSA stops supporting a particular system, *that
> > system's repository* stops getting the new versions of
> > OMSA.
> Hmmm... I just had an idea, and I wonder if it would work: Create an
> empty package (containing no files), one for each system type. Have
> said packages provide capabilities. Then have the actual software
> packages (e.g., for OMSA) depend on the virtual capabilities. As long
> as you only installed the appropriate empty package for a given
> platform, that dependency should prevent something not supported from
> being installed.
> For example: Say I've got a PowerEdge 9750, so I install the
> "poweredge-9750-capabilities" package. Then say Dell releases package
> "omsa-12.0". Have that OMSA package depend on a capability,
> "supports-omsa-12.0". Then, when the PE 9750 is certified to work
> with the OMSA 12.0 release, update the "poweredge-9750-capabilities"
> package to provide the "supports-omsa-12.0" capability. The
> capabilities package should auto-update, which will then allow the new
> OMSA package to update.
> Note that I have no idea if this would work. But if it did, it
> would save the trouble of having 200 different repositories.
Thanks for the suggestion. For many, many months I had considered
this exact idea, and in fact most of my original designs centered around
something like this. For discussion purposes, I shall name your idea
First, though, let me point out the fact that, for me, having 200
repositories is not a problem for me:
-- Most of the files in the repo are hardlinked together, so it
doesnt take up too much space.
-- The repos are completely automatically generated. It is just as
easy for me to generate one repo as it is to generate 500.
-- I dont have to change any of the specific rpms in the repos. If
an rpm is qualified for a new platform, I dont have to change the
rpm, or any other related rpm, just drop it in the platform repo.
So, all in all, multiple repos works nicely for me. The problem with
the platform-rpm approach is:
-- consider the case where a user moves a hard drive from one
platform to another. With yum-plugin, they automatically point to
the new repo. With platform-rpm, they dont.
-- consider that I need to version-by-platform not just OMSA, but
tons of drivers and such. This means that whenever, say, the e1000
driver revs, I would have to rev the platform-rpm for each platform
affected. Collectively this means that the platform rpm would have
to have a Provides: supports-omsa-12.0, supports-e1000-1.1,
supports-mpt-linux-2.2, supports-megaraid-3.3, supports-e100-4.4,
-- along with the above, and what really kills this idea: I would
have to change RPMs that I dont necessarily own: For example, the
e1000 rpm is generated by Intel, and I would have to ask Intel to
add this and generate a special Dell-specific RPM.
-- This breaks standalone install. We would have to install the
platform RPM for all normal installs as well.
For all these reasons, I have abandoned the platform-rpm concept in
favor of the yum-plugin model.
More information about the Linux-PowerEdge