[ewg] Re: RFC OFED-1.3 installation

[Doug Ledford]

On Mon, 2007-07-16 at 15:24 +0300, Vladimir Sokolovsky wrote:

[ snip ]

Most of this proposal was just about splitting the packages up.  That's
good, but it doesn't warrant much comment.  It's not the existence of
different packages that will draw my comments, it's the *content* of the
packages that will, the actual spec files themselves.

However, there is this one tidbit:

>      Source RPMs will be created for each userspace package in the following way:
> 
>      git clone ...
>      autogen.sh
>      configure --disable-libcheck
>      make dist

This is so fundamentally broken as to be brain dead.  Yet it's what has
been done since OFED 1.0.  Can you imagine how screwed the open source
world would be if one day Linus released kernel-2.6.24.tar.gz on
kernel.org, only to silently update the file kernel-2.6.24.tar.gz to
something else the next?  This is the *ONLY* open source software group
I know of that creates new tar.gz files any time they make a change but
keeps the version of the file the same.

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.]
>  
> Does this means that the OFED 1.3 effort is useless from your point of
view? 

Yes and no.  The effort to get a complete set of working libraries and
stacks pulled together and debugged is good and worthwhile.  The
packaging has been done all wrong though.  Because the ewg has
concentrated on supporting local compile installations, they don't
really have the faintest clue about several important issues that crop
up specifically when you are attempting to support binary distribution
instead of source distribution.  That in turn has led them to make
decisions that have proved to be very counterproductive to my end goal
of a supportable environment for my customers.

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.  Furthermore, unless the person
is compiling locally, they'll never get the OFED 1.1 dapl installed
because RPM/up2date will see that they already have the current version
even when they have the OFED 1.0 version.  So, in our RPMs, I updated
the OFED 1.1 dapl version we built to be 1.2.1.  Without doing that, the
binary upgrade process that we use would have never worked.  Then, in
OFED 1.2, you guys update the dapl code again, and this time you decide
to use...wait for it...that's right, 1.2.1.  Great.  Now we have a
conflict between your 1.2.1 and our 1.2.1.  How do people know which is
which?  They don't.  And, of course, in order for binary upgrades to
work, I once again had to bump our number.  Our OFED 1.2 package now
builds dapl 1.2.1.1 just because I had to do *something* in order to
make upgrades work.

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.

So, quite simply, the EWG has *chosen* to support source distribution
and local compiles.  That's fine really.  But they've also chosen to
bury their head in the sand about basic, non-flexible rules associated
with any successful binary distribution and update process, even when
I've brought those rules up multiple times.

It should be no wonder then why I get all up in arms about packaging
issues.  Everything I give my customers has to automatically and
correctly install, upgrade, downgrade, delete, verify, etc using
RPM/up2date/yum.  It can't require any --force options.  And I don't
have a choice about that.

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.

------- End cut-n-paste

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've already reached the decision that the next release of the RDMA
stack that Red Hat releases will adhere to much stricter guidelines than
in the past.  From now on, all packages I build based upon software from
the OpenFabrics Alliance will adhere to these guidelines:

1.  All tar.gz files will be imported once and exactly once into our SCM
repo.  At that point they will be MD5 summed and the MD5 sum will be
checked on all subsequent builds to verify the tar.gz file has not
changed.

2.  All fixes to released tar.gz files will be in the form of patches
applied in the spec file during the %prep phase, or they will require a
new tar.gz file.  Under no circumstances will an existing tar.gz file be
updated to include fixes.

3.  All packages will have a version and release number appropriate to
the tar.gz release of the software and the build of the package.

4.  All tar.gz files *must* have a publicly available URL from which
they can be downloaded.

5.  All tar.gz files that have a home site other than openfabrics.org
will be taken from their home site.  Eg. openmpi will come from the
openmpi site.  No special openfabrics versions of already existing
packages will be considered.

6.  All source repos that utilize the autoconf configure capability will
have configure run at build time.  Any configure output produced prior
to build will not be considered usable.  On the other hand, we expect
that autogen.sh *will* be run prior to making the tarball.

If the software does not meet the above minimal guidelines, then it
won't be considered for inclusion in our product.

In addition to these rules, if you want me to consider using your spec
files to build the packages, then these additional rules apply:

7.  All spec changes will be accompanied by a changelog entry.

8.  The spec file will be clean and readable.  Spec files cluttered up
with multitudes of options that have no impact on a standardized
distribution will not be included.

9.  All spec files must be Linux File Hierarchy Standards compliant.

10. All spec files must pass rpmlint tests.

11. All code must be built using the %build section of the spec file.
The %install section is for installation *ONLY*.

12. Spec files must build debug packages.

13. Spec files must leave the default build scripts enabled.

14. Spec files must list appropriate BuildRequires entries.

15. Spec files must not list Provides entries unless the build scripts
are unable to determine that they provide a particular item, or in cases
like the MPI packages where they can specify that they provide the
generic mpi facility in addition to the specific mpi library provides
that the build system will pick up automatically.

There's probably more things to list, but I really don't feel like
repeating what amounts to our standard build requirements when they are
already all written out in the guides I talked about in my Sonoma talk.

Hopefully, all of this will help you get a clearer picture of what I
expect the EWG's work on cleaning up their packaging to cover.

-- 
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/ewg/attachments/20070717/547460ea/attachment.sig>