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

[Doug Ledford]

On Tue, 2007-07-17 at 18:36 +0300, Vladimir Sokolovsky wrote:
> [ 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.

This may be true going forward when you've split all the packages up,
but it definitely was *not* true when all the packages where thrown into
one huge tarball and built out of one spec file.  Since the versioning
information was lost when that tarball was recreated over and over
again, versioning responsibility necessarily fell back upon the spec
file.

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

From the viewpoint of proper upgrades, there is no difference.  Removing
and then installing is just a work around for broken upgrades.

> This is why package versioning does not affect OFED installation.

Right, you guys did things in a way that allowed you to not care about
something that any distributor *must* care about.

> I agree that it is different for Linux Distributions

Open Fabrics Enterprise Distribution

>  and should be fixed
> for OFED-1.3 but it should 
> be under responsibility of package maintainer.

The maintainer of any given software is responsible for their tarballs.
The maintainer of any given rpm is responsible for their spec file and
rpms.  If a person takes on both roles, like Roland does, then they
handle both roles and the roles mostly merge into one.  But whenever
someone other than the project maintainer decides to be the package
maintainer, they are different roles and each is responsible for their
own versioning requirements.

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

No, you can't.  At least not on any system running our packages.  We
don't, and won't, include anything like ofed_info in our distribution.
We have one tool, and only one, that we use to tell what software a
system is running: rpm.  We will not include things like ofed_info just
to find out what rpm should, if used properly, already tell us.  That
would be unnecessary duplication and results in all sorts of support
problems when you start needing to be able to tell customers to use
multiple different tools to try and figure out what one tool should be
able to tell them.

> 
> > 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?

autogen.sh yes (and it should have been in my script, my current one has
it, but that one didn't).  Since configure tries to figure out a bunch
of stuff about the build environment, it must be run in the software
development environment of the platform you are targeting the final
build for.  If you run it on your local RHEL4 machine, but our RHEL4
build environment for our next update has a different glibc that changes
some minor thing that configure actually checks, then it would be wrong.
So, even if you run configure, I can't trust the output from it.
Obviously, if you aren't running configure, then make dist is
irrelevant.  So, you can run configure if you want, but I will ignore
the output in anything I build.  And if the make dist operation removes
any files necessary for me to properly reconfigure the software using
configure, then it will be a totally broken tarball from my perspective.

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

I have a newer version of that make.dist script that I wrote to
specifically work for the repos other than the management tree.  Using
that script, you could just do this:

for repo in *; do
    ./make.dist $repo daily
    rm $RPMDIR/${repo}*
    rpmbuild --rebuild dist/$repo-git.tar.gz
    rpm -Uvh $RPMDIR/${repo}*
done

That's really all you need for anything you are building for internal
use.  And if one of you wanted to be responsible for providing the rpms,
then a single person could actually maintain versioned rpms that way.
It would only break down when you try to run the make.dist script from
different systems since it creates a file that lets it know what the
next number in sequence is each time it builds that git.tar.gz file.
However, even that could be solved by putting the release file in some
sort of SCM if you wanted multiple people to be able to build properly
versioned rpms.

Really, the strictest guidelines apply to things you make publicly
available.  If you want to have a private, EWG only area on the ofa
server where you guys can share daily, unversioned builds, go right
ahead.  It's when they go out in the wild and you expect other people to
pick them up that you have to care.

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

From my standpoint, tgz files are really about all I care about.  For
instance, no matter what install script you write, I won't be using it
because we have our own install/update methods.  And it's hard for you
to make a spec file that's both relevant for Red Hat and SuSE and at the
same time clean enough to meet our requirements.

There is one suggestion I would make though that greatly helps with the
whole package versioning issue.  We have this trick we use in our kernel
RPMs back when we used to ship a kernel-source rpm (which was different
than the src.rpm, it was a pre-prepared, already prep'ed source tree
ready to be built from).  When we built our own kernel RPMs, we would go
into the top level Makefile in the kernel source tree and edit the
extraversion to be what matched the rpm.  When we made that source tree
that would become the kernel-source package, we edited extraversion to
-prep so that the final result if a customer used it to build a kernel
would be something like 2.6.9-prep in the kernel version.  You guys
could do something similar in all the src.rpms you ship.  Since you know
they will be compiled locally, you could easily put something
like .local at the end of you release string, so that say dapl would be
version: 1.2.1, release: 1.local or 1.ofa or something like that.  It
doesn't solve package version comparison issues (aka, telling which
package is newer by the number), but it does help to solve
identification issues.

-- 
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/4aad09ac/attachment.sig>