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

[Vladimir Sokolovsky]

[ snip ]
> Let me copy and paste an email conversation I had with Or that
> highlights why this is broken:
> 
> ------- Begin cut-n-paste
> On Mon, 2007-07-02 at 22:25 +0300, Or Gerlitz wrote:
> > [sorry for breaking the thread, I am working from home now and
unable
> to use normal mailer.]
> >


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

I am not suppose to support correct versioning for every package in
OFED.
It should be done by the maintainer of the package.

> The only reason that the OFED distribution has *ever* reliably
> installed the rpms you wanted installed is because you compile things
> locally and then *force* the upgrade of rpms over the top of older
rpms
> that have the same version number.  And even then, you yourselves
can't
> tell the difference between a customer with the OFED 1.0 or OFED 1.1
> dapl installed by checking the RPM version, you just have to go off
> what the end user *tells* you he installed and hope he's right.
> 

OFED does not force an upgrade, it simply removes the previous version
and then installs the new one.
This is why package versioning does not affect OFED installation.
I agree that it is different for Linux Distributions and should be fixed
for OFED-1.3 but it should 
be under responsibility of package maintainer.
So, all RPM spec files should be fixed for OFED-1.3 and properly
maintained.
We should discuss the kernel-ib package structure and its spec file.

> And I have to *know* what software my customer is running in order to
> support them.  Because you guys have done things the way you have, I
> can't know that.  I might be able to know if I could also guarantee
> they didn't download and locally compile your packages, but if they
> did, then the same version number of RPM can mean two different things
> entirely depending on whether it's your RPM or mine.
> 

You can easily check if there OFED installation by running 'ofed_info'.

> I posted links to a wealth of valuable information on the topic of
> making a proper spec file and creating *good* packages during my talk
> at Sonoma.  I gather you haven't read those or you never would have
> suggested the above for creating the RPMs.
> 

I just looked into your presentation from Sonoma. You providing there an
example
of management package and your make.dist script for creating daily
builds and releases.

I have a some questions about this script:
...
 59         VERSION=`grep "AC_INIT.*$target" $target/configure.in | cut
-f 2 -d ',' | sed -e 's/ //g'`
...
 97                 DATE=`date +%Y%m%d`
 98                 if [ -f $TMPDIR/$target.release ]; then
 99                         RELEASE=`cat $TMPDIR/$target.release`
100                         RELEASE=`expr $RELEASE + 1`
101                 else
102                         RELEASE=1
103                 fi
104                 echo $RELEASE > $TMPDIR/$target.release
105                 RELEASE=0.${RELEASE}.${DATE}git
106                 TARBALL=$target-git.tgz
107         fi
...
109         cp -a $target $target-$VERSION
110         sed -e
's/@VERSION@/'$VERSION'/;s/@RELEASE@/'$RELEASE'/;s/@TARBALL@/'$TARBALL'/
' < $target/$target.spec.in > $target-$VERSION/$target.spec
111         cd $target-$VERSION
112         ./autogen.sh
113         cd ..
114         echo "Creating $TMPDIR/$TARBALL"
115         tar -czf $TMPDIR/$TARBALL --exclude=.git $target-$VERSION

I thought that the standard way to get tar.gz file is using autotools (3
commands) like I wrote before:
autogen.sh, configure, make dist.
Can you explain why your way is better?

Do you have a proposal for daily builds? We need OFED daily builds for
verification. 
We can't wait for RedHat updates to get the updated OFED packages.

What OFED-1.3 structure do you propose? Should it consist of source RPMs
or tgz files?
What features install script should support?

Regards,
Vladimir