[ofa-general] Re: [PATCH] uDAPL (dat2.0 branch) - fixup distribution and specfile

[Doug Ledford]

On Thu, 2007-10-25 at 16:46 -0700, Arlin Davis wrote:
> Doug, 
> 
> Please take a look at the patch to cleanup the DAPL distribution
> tarball and spec file.
> 
> Thanks,
> 
> -arlin
> 
> -- 
> Fix DAPL distribution by removing release number from tarball. 
> General spec file cleanup for release 2 targeted for OFED 1.3 beta.
> 
> Signed-off by: Arlin Davis <ardavis at ichips.intel.com>
> --
> diff --git a/configure.in b/configure.in
> index b08e06f..f11a7a2 100644
> --- a/configure.in
> +++ b/configure.in
> @@ -1,11 +1,11 @@
>  dnl Process this file with autoconf to produce a configure script.
>  
>  AC_PREREQ(2.57)
> -AC_INIT(dapl, 2.0.1-1, general at lists.openfabrics.org)
> +AC_INIT(dapl, 2.0.1, general at lists.openfabrics.org)
>  AC_CONFIG_SRCDIR([dat/udat/udat.c])
>  AC_CONFIG_AUX_DIR(config)
>  AM_CONFIG_HEADER(config.h)
> -AM_INIT_AUTOMAKE(dapl, 2.0.1-1)
> +AM_INIT_AUTOMAKE(dapl, 2.0.1)

If you are going to build a new tarball, this should probably be 2.0.2.
And any new tarballs after that should increment that number.

>  AM_PROG_LIBTOOL
>  
> diff --git a/dapl.spec.in b/dapl.spec.in
> index 232f0df..f49b95d 100644
> --- a/dapl.spec.in
> +++ b/dapl.spec.in
> @@ -33,13 +33,13 @@
>  # $Id: $
>  Name: dapl
>  Version: 2.0.1
> -Release: 1%{?dist}
> +Release: 2%{?dist}

This should probably be:

Version: @VERSION@
Release: 1%{?dist}

There is a general issue with including spec files in an upstream
release.  Namely, any distribution is likely to rebuild your release any
number of times for integration issues and fixes.  That means any
distribution is guaranteed to end up producing their own releases of
your version of the software.  If both you and the distros are producing
various releases of the same version of software, then it becomes next
to impossible to map from your version-release combo to the same code in
a distro version-release combo.  So, the spec file may make things easy
for people to build rpms of your code, but in order to play nice with
distros, you really need to update the version of the software and leave
the release at 1 anytime you update your tarball.  Since you don't
maintain your spec files separate from your tarballs, that means even a
spec file change requires a tarball version increment.

Now, if your tarball didn't contain the spec or spec.in file, then you
could update those without having to update the tarball.  But, that
generally means you would need to have both the tarball itself and the
spec file available for people to download.  That way people who are
building rpms locally have the benefit of you being able to release
updated specs without updating the tarball, and distros have a reliable,
authoritative tarball download that doesn't change unless the source
changes.

I'm fine with either way, but let's say you uploaded dapl-2.0.1.tar.gz
with the original spec file, then re-uploaded the exact same
dapl-2.0.1.tar.gz with this updated spec file, then that would be
*horribly* broken.  You can't have two different tarballs with the same
name.  I know the original dapl updload was 2.0.1-1, but the way things
are headed with this update, if you *did* do a -3 release, it would
overwrite the -2 release tarball silently.

>  Summary: A Library for userspace access to RDMA devices using OS
> Agnostic DAT APIs.
>  
>  Group: System Environment/Libraries
>  License: Dual GPL/BSD/CPL
>  Url: http://openfabrics.org/
> -Source:
> http://www.openfabrics.org/downloads/%{name}/%{name}-%{version}-%{release}.tar.gz
> +Source:
> http://www.openfabrics.org/downloads/%{name}/%{name}-%{version}.tar.gz
>  BuildRoot: %(mktemp -ud
> %{_tmppath}/%{name}-%{version}-%{release}-XXXXXX)
>  Requires(post): /sbin/ldconfig
>  Requires(postun): /sbin/ldconfig
> @@ -72,7 +72,7 @@ Requires: %{name} = %{version}-%{release}
>  Useful test suites to validate uDAPL library API's.
>  
>  %prep
> -%setup -q -n %{name}- at VERSION@
> +%setup %{name}-%{version}

You don't need the %{name}-%{version} without -n.  The whole purpose of
-n is to tell the setup script that the tarball unpacked into a
directory *other* than %{name}-%{version}, and then the argument to -n
is the directory it actually unpacked into.  You might want to keep the
-q on the other hand, it just keeps them from passing -v to the tar
extract command.

>  %build
>  %configure --enable-ext-type=ib 
> @@ -99,6 +99,7 @@ rm -rf %{buildroot}
>  %files devel
>  %defattr(-,root,root,-)
>  %{_libdir}/*.so
> +%dir %{_includedir}/dat2
>  %{_includedir}/dat2/*
>  
>  %files devel-static
> @@ -111,6 +112,9 @@ rm -rf %{buildroot}
>  %{_mandir}/man1/*
>  
>  %changelog
> +* Thu Oct 25 2007 Arlin Davis <ardavis at ichips.intel.com> - 2.0.1-2
> +- OFED 1.3-beta,   DAT/DAPL Version 2.0.1 Release 2
> +
>  * Tue Sep 18 2007 Arlin Davis <ardavis at ichips.intel.com> - 2.0.1-1
>  - OFED 1.3-alpha, co-exist with DAT 1.2 library package.  
>  
> 
-- 
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/20071026/9abab48e/attachment.sig>