[ewg] Re: RFC OFED-1.3 installation

[Doug Ledford]

On Tue, 2007-07-17 at 20:45 +0300, Michael S. Tsirkin wrote:
> > There are lots of things that we as a distributor have to care about
> > that upstream generally does not.  The spec file and patches are how we
> > solve our customer's problems.  They are what make a stable
> > distribution, as opposed to a "bleeding edge, must always update to
> > latest upstream version to fix any problem" system, a reality.  It's the
> > difference between RHEL and Fedora.
> 
> I think I am getting it - you want to release a patched version of some OFED
> library without going through openfabrics? OK.
> So I imagine that's when you would increment the rpm-specific version number.
> But I can't see why would an OFED release want to play with these.

You don't want to, you *have* to.  It's because you are distributing
source software packages that build RPMs.  And you aren't waiting until
OFED is final, you release pre-releases too.  So you need to be able to
tell the difference between a customer running libibverbs-1.0.4 from
OFED-1.3-beta1 and libibverbs-1.0.4 from OFED-1.3 final.  In order to do
so, they need a different release number because the version number is
the same.  The only way this changes is if every component of OFED 1.3
releases their final tar.gz file in concert with OFED 1.3.  Otherwise,
at least *some* items in there will need a bumped release number.

Unless of course you are just relying on ofed_info, which as I pointed
out in my last email, is a workaround for not doing this.  We *won't*
use that workaround because having two means to tell the same thing
increases our support personnel training costs and makes things more
confusing for the customer.  We have one tool already, that's good
enough.

Additionally, once you step into the "create rpms" space, there are only
two ways things can go.  You can adhere to RPM packaging standards, and
your custom built RPMs will peacefully coexist on a system were there
are similar RPMs coming from the OS distributor, aka Red Hat.  Or, you
can do what you've been doing, where RPMs you build don't maintain
consistent numbering, and the customer can end up getting screwed when
your RPMs and our RPMs collide.

It would be careless and reckless to risk customer systems going belly
up because your RPM and mine collide in a way that renders the machine
dysfunctional.

So don't think of it as playing games with bumping release numbers,
think of it as finally making OFED RPMs standard compliant so you no
longer need the workaround of ofed_info.

-- 
Doug Ledford <dledford at redhat.com>
              GPG KeyID: CFBFF194
              http://people.redhat.com/dledford

Infiniband specific RPMs available at
              http://people.redhat.com/dledford/Infiniband
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openfabrics.org/pipermail/ewg/attachments/20070717/21edc5a8/attachment.sig>