[ewg] RE: RFC OFED-1.3 installation
Vladimir Sokolovsky
vlad at mellanox.co.il
Tue Jul 17 08:36:23 PDT 2007
[ 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
More information about the ewg
mailing list