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

Michael S. Tsirkin mst at dev.mellanox.co.il
Tue Jul 17 10:12:50 PDT 2007


> Quoting Doug Ledford <dledford at redhat.com>:
> Subject: Re: RFC OFED-1.3 installation
> 
> On Tue, 2007-07-17 at 19:45 +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 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.
> > 
> > OK.
> > 
> > > ...
> > > You also bump the release number of the package any time you make
> > > changes to the spec file and rebuild.
> > 
> > Since we have spec files as part of package, this will be really
> > the same as the previous case, right?
> 
> Depends.  Right now the spec file gets its version out of the configure
> stuff.  That version only updates when you update the version of the
> software itself.  It doesn't increment on each change to the source
> repo, only on the major updates when you would release a new tarball
> anyway.  Package versioning is, by necessity, finer grained than source
> repo versioning.  You don't release a new dapl tarball just because you
> updated some comments to remove a typo.  But you *do* update rpm
> versions on every single change, at least if you are going to distribute
> the rpm.
> 
> Look, rpms are just like versioned tarballs.  Once they go out in the
> wild, that particular name-version-release combination is FROZEN.

It really looks like this is a work around for when you want to apply
a patch without going through maintainer.

The way OFED release process works, we really don't
do releases all that often, and when we do, we can coordinate with
the maintainer.

-- 
MST



More information about the general mailing list