[ofa-general] Re: RFC OFED-1.3 installation

[Doug Ledford]

On Tue, 2007-07-17 at 19:27 +0300, Michael S. Tsirkin wrote:
> > Quoting Doug Ledford <dledford at redhat.com>:
> > Subject: Re: RFC OFED-1.3 installation
> > 
> > On Tue, 2007-07-17 at 18:25 +0300, Michael S. Tsirkin wrote:
> > > > Let me give an example.  In OFED 1.0, you shipped dapl version 1.2.  In
> > > > OFED 1.1, you also shipped dapl version 1.2.  However, code inspection
> > > > shows that between OFED 1.0 and OFED 1.1, dapl did in fact change (not a
> > > > lot, but anything is enough).  So, between OFED 1.0 and OFED 1.1, you
> > > > have two different versions of dapl, but with exactly the same version
> > > > number.  A person can't tell them apart.
> > > 
> > > Yes, this sure looks like a problem. I think that versioning needs to be addressed
> > > at the package level, not at OFED level though. Right?
> > 
> > Versioning needs to be addressed at both levels.  You need versions of
> > software to start with, but then you still need releases of packages to
> > differentiate between different builds of a specific version of
> > software.
> 
> Why would we want to have different builds of a specific version of software
> for a specific OS?  Could you give an example pls?

It's how you integrate needed patches immediately while waiting on the
next release of the software.  For example, when mdadm-2.6.2.tar.gz was
released, I built an mdadm-2.6.2-1 package (the 1 being the release
number).  I then went to work on some mdadm bug reports I had, and I
wrote a number of patches that squashed about 10 bug reports.  During
that time, I had three intervening builds as I integrated those patches
into the spec file and applied them to the 2.6.2 base source code during
the build process.  Those builds were 2.6.2-{2,3,4}.  I also forwarded
those patches upstream, they've been integrated into the upstream code
base, but a 2.6.3 has not yet been released, the upstream maintainer is
waiting until everything he's putting into it settles down.  When 2.6.3
is released, then I'll integrate 2.6.3 into our source SCM system, drop
all of the patches that have been integrated into the base 2.6.3 source
code, and build mdadm-2.6.3-1.

The point of all this being that most software maintainers don't release
new versions of their software on a daily or even weekly basis, so when
you are busy fixing up bugs in the software between releases, the
patches go in the spec file and you bump the release number so that each
subsequent build has a unique number that can positively identify both
the base source code used and all patches applied to that source code.

You also bump the release number of the package any time you make
changes to the spec file and rebuild.  So, for instance, if the only
change I made to a package was to change the %doc macro in the %files
section, I would still bump the release number and rebuild so that the
new rpm name-version-release combination would uniquely identify the
change.

-- 
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/general/attachments/20070717/2688105b/attachment.sig>